Offline-First ist eine Architektur
Außendienst-Apps brauchen keine bessere Fehlerbehandlung für verlorene Verbindungen. Sie brauchen ein Datenmodell, das das Netz nie vorausgesetzt hat.
Es gibt eine Version von Offline-Unterstützung, bei der die App den Verbindungsverlust erkennt, eine Meldung zeigt und es erneut versucht. Das funktioniert in einer Demo und scheitert im Keller, denn der Fehler ist nicht die Anfrage — sondern dass die Nutzerin vierzig Minuten weitergearbeitet hat, während die Anfrage unmöglich war.
Offline-First dreht das Verhältnis um. Die lokale Datenbank ist die führende Quelle. Die Oberfläche liest und schreibt lokal und wartet nie auf einen Netzaufruf. Synchronisation ist ein Hintergrundprozess, der abgleicht, wann immer er kann, und die Nutzerin wird davon nie blockiert.
Damit ist die Ausgangswarteschlange die wichtigste Komponente der App. Jede Änderung wird vor der Ausführung an ein dauerhaftes Journal angehängt, sodass eine mitten im Upload beendete App am letzten gültigen Eintrag weitermacht, statt die Arbeit zu verlieren. Das ist der Unterschied zwischen einem Techniker, der abends einen Tag Aufträge neu eintippt, und einem, der es nicht tut.
Konflikte werden dann zu einer Produktentscheidung statt zu einem technischen Zufall, und sie sollten vor der ersten Zeile Code geklärt sein. Im Außendienst haben wir uns auf Server-gewinnt bei Preisen und Terminen festgelegt, Gerät-gewinnt bei Beobachtungen vor Ort und eine Ausnahmewarteschlange für alles andere.
Die Nutzlastgröße zählt mehr, als Teams erwarten. Delta-Sync statt Vollabgleich, komprimierte und stückweise fortsetzbare Foto-Uploads und ein hartes Budget dafür, was eine Synchronisation an Daten und Akku kostet. Eine korrekte App, die das Telefon bis mittags leert, ist keine funktionierende App.
Bei einem Einsatz mit neunhundert Montagetechnikern hat das die Bearbeitungszeit je Auftrag um zweiundvierzig Prozent gesenkt und die Zahl verlorener Aufträge von rund vierzig im Monat auf null. Nichts davon kam aus der Oberfläche.