Scanner-App neu — UX-Konzept

Stand 2026-09-03 · Programm Replikation · Meilenstein R4 · Epic „Scanner-App neu" · Task E2 (NXN7HJM)
Vorgabe für den Bau-Task 6a9932ac6edab122065e8462 (REP2). Alle Ist-Zahlen sind an der ausgebrachten
App unter scanner.ayoune.app gemessen, nicht geschätzt.

1 Befund — was heute gemessen ist

Anlass ist der CEO-Befund vom 2026-09-03: *„die Bedienung ist schwerfällig, die Oberflächen unklar
und schlecht lesbar … der Scanner-App fehlt ein Einstieg zum Verwalten von Lagern und Lagerorten."*
Die folgenden Zahlen belegen ihn.

1.1 Die Startseite bietet elf gleichrangige Wege und keinen einzigen zu den Stammdaten

scan-home.component.ts:161-201 führt elf Kacheln — Wareneingang, Einlagern, Umlagern,
Kommissionieren, Material, Nachschub, Retouren, Inventur, Korrektur, Batch-Scan, Kamera-Scan —
alle in derselben Größe, derselben Farbe, ohne Gruppierung. Dazu eine Scan-Zeile darüber und ein
Benutzer-Menü mit Verlauf/Einstellungen/Abmelden.

Kein Einstieg für Lager, Lagerorte, Produkte oder Prozess-Ketten. Wer wissen will, was in
Regal A liegt, hat von der Startseite aus keinen Weg dorthin.

Elf gleichrangige Ziele sind zugleich elf Entscheidungen bei jedem Öffnen der App. Bei 412 px
Gerätebreite misst eine Kachel 200 × 100 px, der Block 660 px über sechs Reihen — die
Startseite füllt den Bildschirm allein mit der Auswahl.

1.2 Lesbarkeit — die Grundschrift ist zu klein, die Kacheln haben keine Grenze

🔴 Der schärfste Einzelbefund ist nicht die Schriftgröße, sondern die fehlende Kachel-Grenze.
Frisch geladen, ohne jeden Eingriff, im Dunkelmodus: die Kachelfläche ist rgb(26,27,31), der
Seitengrund rgb(18,19,22) — 1,08 : 1. Der Rand trägt dieselbe Farbe wie die Fläche, also
ebenfalls 1,08 : 1. Und der Marken-Akzentstreifen, der die Kachel 2026-07-04 ausdrücklich
gebrandet hat, löst über --brand-primary zu exakt der Kartenfarbe auf: **1 : 1, er ist nicht
vorhanden.** Auf einem Werkstattgerät bei Streiflicht steht damit ein Raster aus Text ohne
sichtbare Behälter — genau der Eindruck „unklar", den der Befund beschreibt.

Was dagegen in Ordnung ist und nicht angefasst werden muss: Textkontraste. Kachel-Beschriftung
15,2 : 1, Eingabetext 16,1–16,5 : 1, Kopfzeile 12,95 : 1, Feld-Beschriftung 6,5 : 1 — alle über AA,
in hell wie dunkel.

⚠ Korrektur einer eigenen Zwischenmessung: ein früherer Wert von 1,6 : 1 für die
Feld-Beschriftung im Hellmodus war ein Artefakt der Messung — er entstand beim Umschalten des
Themas über das data-theme-Attribut, bevor Material seine Farbe neu berechnet hatte. Frisch
geladen misst dieselbe Stelle 6,5 : 1. Der Wert gehört nicht in die Mängelliste.

1.3 Die geteilte Scan-Eingabe hat null Nutzer

shared/components/scan-input.component.ts existiert und ist sauber gebaut — sie speist den
app-weiten Scan-Bus. Gemessen: rg -l "app-scan-input|ScanInputComponent" src/app/pages = 0.
Keine der 17 Seiten benutzt sie; die Startseite baut ihre Eingabe selbst, die Prozess-Seiten
bauen je eigene Felder. Positiv-Kontrolle: 13 der 17 Seiten importieren den ScannerService, die
Suche greift also.

Am Prozess-Bildschirm /pick heißt das konkret: vier Formularfelder, keine Scan-Leiste, und
Lagerplatz sowie Produktname sind Freitext-Eingaben — obwohl beide Werte in der Datenbank
geführt werden. Das verstößt gegen die Plattform-Regel, dass ein Feld, dessen Werte die Datenbank
kennt, ein Auswahlfeld ist und kein Textfeld.

1.4 Was bereits erledigt oder vergeben ist — und deshalb keine Lücke ist

Diese Punkte trägt das Konzept als Voraussetzung, nicht als Forderung:

🔴 Prämissen-Korrektur, gemessen: der Auftrag führte „vier scan-blinde Seiten". Das trifft für
den Handscanner nicht mehr zu — seit dem Scan-Bus im Shell erreicht ein Scan jede Route,
auch Rückmeldung, Produkt-Detail, Verlauf und Lagerort-Detail. Die verbliebene Lücke ist eine
andere und betrifft sechs Seiten: sie zeigen keine sichtbare Scan-Leiste und bieten keinen
manuellen oder Kamera-Weg. Betroffen: callback, product-detail, scan-history,
storage-area-detail, settings und — überraschend — scan-home, deren eigene Eingabe am Bus
vorbeiläuft (onScanSubmit() statt scanBus.emit).

2 Entscheidungen des CEO vom 2026-09-03

Fünf Fragen wurden vorgelegt, fünf sind beantwortet. Sie sind ab hier bindend.

⚠ Entscheidung 2 fiel gegen die Empfehlung dieses Konzepts (oben, unter der Kopfzeile). Die
Begründung des Entscheids trägt: die manuelle Eingabe und der Kamera-Knopf sind damit einhändig
erreichbar. Der Preis wird in Abschnitt 4.1 benannt und ist beim Bau zu beachten.

3 Informationsarchitektur

3.1 Sechs Einstiege statt elf Kacheln

Die Startseite führt genau sechs Einstiege. Jeder hat einen anderen Zweck; kein Einstieg ist eine
Teilmenge eines anderen.

Warum sechs und nicht elf: die elf heutigen Kacheln sind alle Prozesse — sie gehören unter
einen Einstieg. Was fehlte, waren die drei Stammdaten-Wege (Lager, Lagerorte, Produkte), genau
die, die der CEO-Befund benennt. Elf minus zehn Prozesse plus drei Stammdaten plus Scannen plus
Einstellungen ergibt sechs.

Tiefe bis zur Aktion: höchstens zwei Schritte. Startseite → Prozess-Kette → Arbeitsschritt.
Startseite → Lagerorte → Lagerort (mit allen Aktionen). Der Lagerort-Baum hat zwar fünf Daten-Ebenen
(Lager › Regal › Fach › Box › Zelle), aber nie fünf Klick-Ebenen: ein gescanntes Zell-Etikett
springt direkt auf die Zelle, und die Liste zeigt je Ebene Zähler statt Nachladen.

3.2 Rollen ändern die Reihenfolge, nie den Umfang

🔴 Alle sechs Einstiege bleiben in jeder Rolle sichtbar, und Scannen funktioniert in jeder Rolle.
Eine Rolle, die einen Einstieg entfernt, wäre eine Sperre — und Sperren nach Rolle sind
ausdrücklich verboten (CEO 2026-08-30). Die Rolle darf ausschließlich Startseite, Reihenfolge und
Menü bestimmen.

3.3 Pfadschema und Migration aller 19 heutigen Routen

Schema nach Entscheidung 1: /<modul>/<entität>[/:id], wie in der Haupt-PWA. Prozesse sind
Unterseiten der Entität processes.

Neu, ohne alten Vorgänger: /warehouse/warehouses · /warehouse/warehouses/:id ·
/warehouse/storageareas (Suche) · /pim/products (Suche) · /warehouse/processes (Ketten-Übersicht).

🔴 Alle Weiterleitungen sind dauerhaft, nicht befristet. Grund: die Kiosk-Geräte tragen ihre
Startadresse im Geräteprofil, MDE-Geräte tragen sie als Verknüpfung auf dem Startbildschirm, und
beides wird nicht zentral nachgezogen. Eine entfernte Weiterleitung zeigt dort eine leere Seite,
und niemand meldet es — das Gerät läuft ja.

4 Die einheitliche Scan-Leiste

Es gibt genau eine Scan-Leiste als Bauteil, und sie steht auf jeder Seite. Sie ist die
sichtbare Seite des bereits gebauten Scan-Busses — das Konzept legt fest, was man sieht, nicht wie
der Bus arbeitet.

4.1 Position

Fest am unteren Rand, als unterstes Element jeder Seite (Entscheidung 2). Die Primäraktion
liegt direkt darüber.

⚠ Der Preis dieser Wahl, damit er beim Bau nicht überrascht: auf dem Pi-Kiosk (1920 × 1080,
Wandmontage, kein Daumen) sitzt die Leiste am unteren Bildrand und damit weit vom Blickpunkt
entfernt; auf dem MDE mit Hardware-Taste wird sie ohnehin selten berührt. Gegenmaßnahme im Bau:
der Erfolgs- und Fehlerzustand wird zusätzlich vollflächig als kurzes Overlay gezeigt
(Abschnitt 4.2), damit die Rückmeldung nicht ausschließlich am unteren Rand hängt. Ohne dieses
Overlay wäre die untere Leiste auf dem Kiosk eine Verschlechterung.

4.2 Die fünf Zustände

Das Overlay bei Erfolg ist bewusst vollflächig und kurz: beim Scannen ist das Gerät nicht am Auge,
die Rückmeldung muss peripher ankommen. Die Dauer von 800 ms liegt in dem Fenster, das Zebra für
seine eigene Umsetzung vorgibt (500–1500 ms, Vorgabe 1000 ms).

🔴 Der Fehlfall muss von der App hörbar gemacht werden, nicht vom Gerät. Gemessen an den
Handbüchern: bei Honeywell ist die Erfolgsmeldung ab Werk an, die Fehlermeldung ab Werk aus,
die Vibration ebenfalls aus. Auf der Handy-Kamera gibt es gar keinen Geräte-Piep. Wer sich auf das
Gerät verlässt, hat einen stummen Fehlerkanal — und ein stummer Fehlscan ist im Lager teurer als
ein stummer Erfolg.

4.3 Eingabewege und Regeln

• Drei Wege, ein Ergebnis: Handscanner (Tastatur-Emulation), Kamera, manuelle Eingabe. Alle

drei laufen über denselben Bus, also über denselben Handler — ein getippter Code verhält sich
exakt wie ein gescannter.

• Auf den Terminator warten (CR/LF), nicht auf eine Zeitspanne raten. Bei der Einrichtung eines

Geräts wird geprüft, ob es überhaupt einen sendet; Honeywell liefert ab Werk 9,10 und nicht
die 13, was der häufigste Grund für „der Scan kommt an, aber nichts passiert" ist.

• Fokus-Riegel: solange ein Textfeld den Fokus hat, feuert der Handscanner nicht in die Leiste

(bereits gebaut, ignoreIfFocusOn).

• Doppelscan-Sperre, Vorgabe 800 ms je Code. Ohne sie feuert die Kamera denselben Code

fortlaufend, solange er im Bild bleibt.

• Kamera-Knopf nur, wo eine Kamera vorhanden ist. Auf dem MDE erscheint er nicht.

4.4 Was nach einem Treffer geschieht

Nach Entscheidung 3 hängt die Regel an der Code-Art, und die Code-Art kommt aus
modelsAndRights.barcodePrefix — sie wird nicht ein zweites Mal in der App gepflegt.

Läuft gerade ein Arbeitsschritt (z. B. eine Pick-Position), gilt der Handler dieses Schritts und
nicht die Vorgabe: ein Lagerort-Scan bestätigt dort den Platz, statt eine neue Seite zu öffnen.

4.5 Die sechs Seiten ohne sichtbare Leiste

Diese sechs bekommen die Leiste; keine Ausnahme, auch nicht die Einstellungen:

⚠ callback ist der einzige Sonderfall: die Seite lebt Sekunden und hat keine Sitzung. Die Leiste
steht dort, damit die Anordnung nicht springt, ist aber im Zustand „nicht bereit".

5 Lesbarkeit und Bedienung — die Token-Tabelle

Vorgabe ist das Werkstatt-Niveau (Entscheidung 5). Es ist die Grundeinstellung, nicht ein
Sonderweg; ein „Kompakt"-Schalter bleibt für die Büro-Nutzung.

5.1 Schrift und Abstände

5.2 Zielgrößen

Die 48 px sind der Material-Wert und decken zugleich die aus der Forschung abgeleitete physische
Untergrenze von 10 mm für Handschuhbetrieb (48 CSS px ≈ 12,7 mm) ab. **Der Handschuh-Modus des
Geräts ist aus einer Web-Anwendung nicht setzbar** — Zebra schaltet ihn im Android-System und
liefert ab Werk „nur Finger". Die Größe ist deshalb die einzige Stellschraube, die wir haben.

5.3 Kontrast, hell und dunkel

Soll: 7 : 1 für Text (WCAG AAA — die einzige belastbare Zahl für Blendungsfestigkeit),
3 : 1 für Ränder, Symbole und Flächengrenzen (WCAG 1.4.11).

Was daraus für den Bau folgt: die Textfarben sind in Ordnung und bleiben. Zu bauen sind die
Flächengrenzen — eine Kachel braucht im Dunkelmodus eine Fläche oder einen Rand mit
mindestens 3 : 1 gegen den Grund, und --brand-primary darf im Dunkelmodus nicht zur Kachelfarbe
auflösen. Die Feld-Beschriftung wird von 6,5 auf ≥ 7 : 1 gehoben, das ist eine Ton-Stufe.

5.4 Werkstatt-Bedingungen

• Einhand-Zone: Primäraktionen liegen in den unteren 60 % des Bildschirms. Gemessen liegen

heute 7 von 11 Kacheln dort — das bleibt so und gilt künftig auch für die Aktionsknöpfe.

• Handschuh: keine Bedienung, die nur über Wischen erreichbar ist; kein Zustand, der nur beim

Überfahren mit der Maus sichtbar wird; kein Doppeltippen als einziger Weg.

• Blendung: 7 : 1 als Vorgabe, keine großen hellgrauen Flächen auf Weiß, keine Information

allein über Farbe (immer Farbe und Zeichen/Text).

• Ton und Vibration: drei Kanäle (Bild, Ton, Vibration) einzeln schaltbar, mit eigener

Lautstärke. Erfolg und Fehler klingen unterschiedlich.

5.5 Ladeanzeige, Fehler- und Leerzustände

• Jeder Klick zeigt sofort eine Ladeanzeige (@tolinax/ayoune-loader): inline im Knopf bei

einer Buchung, container beim Nachladen einer Liste, overlay nur beim Seitenwechsel mit
Datenholung. Ein stiller Klick gilt als Defekt.

• Fehlerzustand: was passiert ist in einem Satz ohne Fehlercode · was jetzt zu tun ist als

Knopf · der gescannte Code bleibt sichtbar.

• Leerzustand: je Bereich ein eigener Text plus genau eine angebotene Handlung.
• Keine Hinweise auf laufende Entwicklung in der Oberfläche — kein „folgt", kein „in Arbeit",

kein interner Name.

5.6 Textschlüssel

Alle Texte liegen als Schlüssel im Namensraum scanner.* in ayoune translations (de/en/es/it).
Das Konzept liefert die Gliederung, nicht die Übersetzungen:

scanner.home.*            Kacheln, Rollenhinweis, „Zuletzt gescannt"
scanner.scanbar.*         die fünf Zustände, Eingabewege, Fokus-Hinweis
scanner.warehouse.*       Lager, Lagerort, Zelle, Raster, Etiketten
scanner.product.*         Suche, Detail, Anlage
scanner.process.<kette>.* je Kette: Titel, Schritte, Ausgänge
scanner.settings.*        die vier Gruppen aus Wireframe 7
scanner.error.*           Fehlertexte, je Fall ein Schlüssel
scanner.empty.*           Leerzustände, je Bereich ein Schlüssel

6 Geräteklassen und Referenzvergleich

6.1 Die Matrix

🔴 Was in jeder Klasse identisch ist: die sechs Einstiege, die Pfade, die Scan-Leiste mit ihren
fünf Zuständen, die Ziel- und Schriftgrößen, und dass Scannen funktioniert. Der Kiosk skaliert,
er vereinfacht nicht — eine Klasse, der eine Fähigkeit fehlt, wäre eine Sperre.

6.2 Was aus den Referenz-Geräten übernommen wird

⚠ Prämissen-Korrektur: der Auftrag nannte „Zebra Design Guidelines for Enterprise Mobile Apps"
und „Honeywell Enterprise App Design". Beide Dokumente existieren öffentlich nicht. Zebra und
Honeywell publizieren keine UX-Zahlen für Schriftgröße, Kontrast oder Zielgröße; ihre
Entwickler-Dokumentation ist Geräte- und Scan-Konfiguration. Auch „Zebra Mobility DNA" ist ein
Produkt-Portfolio, kein Regelwerk, und „Honeywell Operational Intelligence" ist Geräte-Analytik
(Batteriegesundheit, Scan-Volumen), keine Bedienrichtlinie.

Was sie sehr wohl publizieren — und was wertvoller ist — ist die Scan-Semantik. Die Zahlen für
Schrift, Kontrast und Zielgröße in Abschnitt 5 stammen deshalb aus WCAG 2.2, Material und der
Touch-Target-Forschung, nicht von den Geräteherstellern.

Zehn übernommene Muster:

1. Ein dauerhaft fokussiertes Sammelfeld für die Handscanner-Eingabe, mit Fokus-Rückgewinnung

nach jedem Dialog — sonst gehen Scans lautlos verloren.

1. Auf den Terminator warten (CR/LF), nicht auf eine Zeitspanne raten.
2. Bei der Einrichtung prüfen, ob das Gerät überhaupt einen Terminator sendet — Honeywell

liefert ab Werk 9,10 ohne die 13.

1. Zeichen puffern, nicht je Zeichen zeichnen — die Hersteller-Notlösung dafür ist eine

künstliche Verzögerung von bis zu 1000 ms je Zeichen, was pro Scan Sekunden kostet.

1. Erfolg als kurzes, vollflächiges Overlay (Zebra: 500–1500 ms, Vorgabe 1000 ms), nicht als

Hinweis in einer Ecke — beim Scannen ist das Gerät nicht am Auge.

1. Fehlfall anders quittieren als Erfolg — und daran denken, dass er ab Werk stumm ist.
2. Drei Rückmeldekanäle getrennt schaltbar (Bild, Ton, Vibration), mit eigenem Lautstärkeweg.
3. Doppelscan-Sperre je Code, Vorgabe 800 ms.
4. Bei mehreren Codes im Bild nur den in der Mitte nehmen (Zebras „Picklist"-Prinzip), Zielhilfe

je Arbeitsschritt schaltbar.

1. Auslöse-Verhalten am Arbeitsschritt, nicht an der App — Einzelscan beim Bestätigen,

Dauerscan beim Wareneingang.

Fünf Muster, die bewusst nicht übernommen werden:

1. Intent-Ausgabe statt Tastatur-Emulation — eine Web-Anwendung hat keinen Empfänger dafür.

Nur eine native Hülle könnte es, und die würde die vier Klassen auseinanderreißen.

1. DataWedge-Profile zur Laufzeit umschalten — Zebra-eigen; Handy, Kiosk und MDE anderer

Hersteller können es nicht. Als Architektur-Annahme untauglich.

1. Zebra Enterprise Browser als Laufzeitumgebung — proprietär, zwei Codebasen, Bindung an

einen Hersteller.

1. Sich auf das Gerätefeedback verlassen (Piep, LED, Vibration) — auf der Handy-Kamera gibt es

das nicht, am Kiosk ist es ein unkontrollierbarer Piep, eine LED ist aus dem Web nicht
ansteuerbar. Die App erzeugt ihre Rückmeldung selbst.

1. Künstliche Zeichenverzögerung als Lösung für verlorene Zeichen — ein Notnagel, der bei einem

20-stelligen Code bis zu 20 Sekunden kostet. Robustes Puffern statt Verlangsamen.

7 Wireframes

Neun Strichzeichnungen, Maßstab 412 × 915 CSS px. Quellen als SVG unter
.claude/reports/replikation/scanner-ux-konzept/wireframes/.

7.1 Startseite, Rolle Werker

7.2 Startseite, Rolle Lagerleiter — dieselben sechs Kacheln, andere Reihenfolge

7.3 Die Scan-Leiste in ihren fünf Zuständen

7.4 Lager — der Baum und der Sprung per Scan

7.5 Lagerort-Detail mit Zellraster

7.6 Prozess-Schritt Kommissionieren

7.7 Einstellungen, nach Arbeitsaufgabe gruppiert

7.8 Fehlerfall und Leerzustand

7.9 Geräteklassen-Matrix

8 Bau-Schnitt für Task 6a9932ac6edab122065e8462 (REP2)

Reihenfolge nach dem Kriterium: was danach sofort besser ist, ohne auf etwas anderes zu warten.

8.1 Bundle-Grenze — ausdrücklich benannt

Die App liegt an einer harten Grenze von 900 kB für das Startpaket (Warnung ab 800 kB), mit
zurzeit rund 37 kB Puffer. Der Scan-Bus hat seinen Standard-Handler genau deshalb ins
Nachladen verschoben (dokumentiert mit +22 kB).

Dieses Konzept zieht keine neue Bibliothek. Alles Nötige ist vorhanden:
@tolinax/ayoune-scan-ui (Wedge-Erkenner), @tolinax/ayoune-loader (Ladeanzeige),
@ngx-translate/core (Texte), Angular Material (Bauteile). Die Token-Änderung ist reines CSS.
Die Scan-Leiste ist eine bestehende Komponente, die ausgebaut wird.

⚠ Wer beim Bau doch eine Bibliothek erwägt (etwa für ein Raster oder ein Diagramm), muss den
Puffer vorher messen und im Handoff nennen. 37 kB sind vier Prozent — ein mittelgroßes Paket
sprengt sie.

8.2 Was dieses Konzept ausdrücklich nicht entscheidet

• Die Gruppierung der Prozess-Ketten — sie kommt aus Task E1 (Prozess-Landkarte), der parallel

läuft. Hier steht nur, dass es einen Einstieg „Prozesse" gibt und dass die Ketten die Gliederung
liefern.

• Der Träger der Verhaltens-Einstellungen — Rolle, Eingabe-Modus, Verhalten nach Scan,

Doppelscan-Sperre, Werkstatt-Modus gehören nach UserSettings; das Feld-Add ist Task
6a9932b76edab122065e8580. Dieses Konzept benennt die Fläche und die Vorgabewerte, nicht das
Schema.

• Die Verdrahtung des Scan-Busses — sie ist gebaut (Brief scanner-scan-bus-und-hardware-matrix,

Task 6a9932a16edab122065e8293). Hier steht, was man davon sieht.

• Der Dunkelmodus-Fehler der Material-Token als Ganzes — der eigene Brief dazu läuft; dieses

Konzept nennt nur die drei Flächen-Kontraste, die die Kachel betreffen.

9 Herkunft der Zahlen

Nicht als Quelle verfügbar: publizierte UX-Richtlinien von Zebra oder Honeywell — sie
existieren nicht (Abschnitt 6.2).