Eine App für den Offline-Betrieb zu entwerfen bedeutet nicht einfach, eine Kopie ihrer Bildschirme zu speichern. Die Entscheidung wirkt sich darauf aus, welche Aufgaben Nutzerinnen und Nutzer erledigen können, wie aktuell die Daten sind, wie sicher das Gerät ist und wie Änderungen behandelt werden, sobald die Verbindung wiederhergestellt ist. Eine offline verfügbare Funktion kann hilfreich sein. Sie kann aber auch in die Irre führen, wenn sie veraltete Informationen anzeigt oder einen Vorgang bestätigt, der den Server noch gar nicht erreicht hat.
Die praktische Frage lautet nicht, ob die gesamte App offline funktionieren soll. Entscheidend ist: Welche Arbeit soll unter welchen Bedingungen weitergehen können, und welche Folgen hat es, wenn die Synchronisierung verzögert wird oder scheitert? Der folgende Rahmen hilft dabei, diese Frage in Produkt- und Architekturentscheidungen zu übersetzen, bevor Sie eine Umsetzung auswählen.
Zuerst klären, was Offline-Betrieb bedeutet
Drei unterschiedliche Ziele werden oft miteinander verwechselt. Ein Offline-Erlebnis ermöglicht es, bestimmte Aufgaben ohne Verbindung zu erledigen und Änderungen für die spätere Übertragung zu speichern. Bei der Toleranz gegenüber Verbindungsabbrüchen soll eine kurze Unterbrechung den Ablauf nicht stoppen, etwa indem ein Entwurf während der erneuten Verbindung erhalten bleibt. Ein eingeschränkter Modus hält einige Funktionen verfügbar, deaktiviert aber jene, die von nicht erreichbaren Daten oder Diensten abhängen.
Diese Ansätze schließen einander nicht aus. Eine App kann ohne Netz aktuelle Einträge anzeigen, Notizen lokal speichern und für die Genehmigung einer Transaktion eine Verbindung voraussetzen. Diese Kombination ist oft sicherer, als vollständige Funktionsfähigkeit zu versprechen. Formulieren Sie den Umfang als klare Regeln: „Entwürfe lassen sich offline erstellen“ ist präziser als „Die App funktioniert offline“.
Ermitteln Sie vor dem Entwurf die Einsatzbedingungen: die übliche Netzabdeckung, die mögliche Dauer von Ausfällen, gemeinsam genutzte oder persönliche Geräte und die Folgen eines Arbeitsstopps. Ein Außendienstteam, das Inspektionen dokumentiert, hat andere Anforderungen als ein Administrationsbereich, in dem Berechtigungen geändert werden. Wenn keine belastbaren Informationen über die tatsächlichen Bedingungen vorliegen, befragen Sie die Nutzerinnen und Nutzer und messen Sie bestehende Netzwerkausfälle. Legen Sie keine angenommene Offline-Dauer zugrunde.
Aufgaben nach Kritikalität und Umkehrbarkeit priorisieren
Erstellen Sie eine Liste von Aufgaben, nicht nur von Bildschirmen. Beantworten Sie für jede Aufgabe folgende Fragen: Ist sie für den Abschluss der Arbeit unerlässlich? Kann sie warten? Welchen Schaden könnte eine Ausführung mit veralteten Informationen verursachen? Lässt sich der Vorgang leicht rückgängig machen oder korrigieren? So hängt die Entscheidung über die Offline-Verfügbarkeit nicht allein davon ab, wie einfach eine Funktion technisch umzusetzen ist.
- Offline fortsetzen: notwendige Aufgaben mit geringem Risiko, deren Daten sich eindeutig speichern lassen, etwa ein Formular ausfüllen oder eine Beobachtung festhalten.
- Mit Einschränkungen zulassen: Aktionen, die zunächst ausstehen dürfen, aber Kontext, Hinweise oder eine spätere Prüfung erfordern. Dazu gehört beispielsweise, einen heruntergeladenen Eintrag zu bearbeiten, wenn das Datum der letzten Aktualisierung sichtbar ist.
- Verbindung voraussetzen: nicht umkehrbare oder sensible Vorgänge sowie Aktionen, für die eine Genehmigung oder die sofortige Verfügbarkeit des Servers erforderlich ist, etwa eine Finanztransaktion zu bestätigen oder Zugriffsrechte zu ändern.
Legen Sie außerdem fest, was geschehen soll, wenn die Verbindung mitten in einer Aufgabe abbricht. Können Nutzerinnen und Nutzer ihre Arbeit verlieren, speichern Sie Entwürfe regelmäßig und ermöglichen Sie deren Wiederherstellung. Lässt sich eine Aktion offline nicht sicher speichern, weisen Sie darauf hin, bevor sie abgeschlossen wird – nicht erst nach einem unerwarteten Fehler.
Lokale Daten nach Aktualität und Schutzbedarf auswählen
Für den Offline-Modus müssen bestimmte Daten auf dem Gerät verfügbar sein. Legen Sie für jeden Datensatz fest, was heruntergeladen wird, wann dies geschieht, wie lange die Daten gespeichert bleiben und wer darauf zugreifen darf. Speichern Sie nur, was für die freigegebenen Aufgaben erforderlich ist: Eine umfangreiche lokale Kopie erleichtert zwar manche Abfragen, erhöht aber das Risiko, wenn das Gerät verloren geht oder eine Sitzung geöffnet bleibt.
Definieren Sie eine verständliche Regel für die Aktualität. Ein Datenstand kann akzeptabel sein, wenn er vor wenigen Minuten aktualisiert wurde, nicht aber, wenn seine Prüfung schon Tage zurückliegt. Zeigen Sie den Zeitpunkt der letzten Aktualisierung an und unterscheiden Sie deutlich zwischen lokal gespeicherten und bereits vom Server bestätigten Informationen. Wird eine Entscheidung durch die Verzögerung riskant, dürfen die Daten nicht als aktuell erscheinen: Beschränken Sie die Aktion oder verlangen Sie eine Verbindung.
Legen Sie auch fest, was bei einer Abmeldung, einem Benutzerwechsel oder dem Verlust des Zugriffs geschieht. Bleiben Entwürfe erhalten? Werden heruntergeladene Daten gelöscht? Kann eine andere Person sie auf einem gemeinsam genutzten Gerät sehen? Die Antwort richtet sich nach der Sensibilität der Informationen und den betrieblichen Anforderungen. Stimmen Sie Speicher- und Zugriffskontrollen mit den Sicherheitsverantwortlichen ab. Gehen Sie nicht davon aus, dass lokale Speicherung automatisch privat ist.
Synchronisierung und Konflikte vor der Umsetzung planen
Eine offline gespeicherte Aktion ist nicht gleichbedeutend mit einer abgeschlossenen Aktion. Die App muss sie als ausstehend behalten, nach Wiederherstellung der Verbindung zu übertragen versuchen und ihren Status mitteilen. Legen Sie für jeden Vorgang fest, was geschieht, wenn die App geschlossen, das Gerät neu gestartet oder die Sitzung beendet wird oder die Verbindung längere Zeit ausbleibt.
Eine Synchronisierungswarteschlange sollte Wiederholungsversuche als normalen Bestandteil des Designs behandeln. Berücksichtigen Sie Unterbrechungen, fehlgeschlagene Antworten und erneute Übertragungen: Könnte ein erneutes Senden einen Vorgang doppelt ausführen, müssen Sie festlegen, wie der Server dieselbe Aktion erkennt. Zeigen Sie erst dann „Abgeschlossen“ an, wenn eine Bestätigung vorliegt. Statusmeldungen wie „Auf diesem Gerät gespeichert“, „Synchronisierung ausstehend“ und „Synchronisiert“ helfen dabei, die Erwartungen richtig zu steuern.
Konflikte entstehen, wenn sich dieselben Daten auf dem Gerät und auf dem Server ändern, bevor die Synchronisierung erfolgt. Es gibt keine allgemeingültige Regel, die jeden Konflikt gut löst. Sie können eine Version beibehalten, unabhängige Felder zusammenführen oder eine Person bitten, die Unterschiede zu prüfen. Welche Lösung passt, hängt von der Bedeutung der Daten ab:
- Bei einer ergänzten Notiz können beide Versionen erhalten bleiben oder neue Einträge angefügt werden.
- Werden Felder getrennt voneinander bearbeitet, kann ein feldweises Zusammenführen unnötiges Überschreiben verhindern.
- Bei Beständen, Zuweisungen oder Statusangaben, die andere Personen betreffen, sollte der Vorgang anhand des aktuellen Stands geprüft werden. Erklären Sie, warum er möglicherweise abgelehnt wird.
Dokumentieren Sie, welche Version Vorrang hat und was Nutzerinnen und Nutzer bei einem Konflikt sehen. Die automatische Regel „Die letzte Änderung gewinnt“ ist einfach, kann aber unbemerkt Arbeit verwerfen. Verwenden Sie sie nur, wenn der Verlust einer Änderung vertretbar und sichtbar ist.
Verbindungsstatus mit sinnvollen Aktionen verknüpfen
Eine Netzwerkanzeige allein reicht nicht aus. Nutzerinnen und Nutzer müssen erkennen können, ob die App verbunden ist, ob ihre Änderungen lokal gespeichert wurden, wie viele noch ausstehen und was zu tun ist, wenn eine Synchronisierung Aufmerksamkeit erfordert. Verwenden Sie konkrete, einheitliche Meldungen dort, wo die Arbeit stattfindet. Setzen Sie „Offline“ nicht mit „Nicht gespeichert“ gleich: Was tatsächlich passiert, hängt von der jeweiligen Aufgabe ab und muss entsprechend kommuniziert werden.
Bieten Sie einen Weg zur Fehlerbehebung an. Schlägt eine Übertragung fehl, zeigen Sie, ob automatisch ein neuer Versuch erfolgt oder ob ein Eingreifen nötig ist. Lehnt der Server eine Änderung ab, nennen Sie den betroffenen Eintrag und bieten Sie sichere Möglichkeiten zur Korrektur. Löschen Sie keine ausstehende Änderung, nur um eine Meldung zu entfernen, und überfordern Sie Nutzerinnen und Nutzer nicht mit technischen Hinweisen, die keine hilfreiche Handlung nennen.
Reale Verbindungsabbrüche testen und Startkriterien festlegen
Tests sollten über das Einschalten des Flugmodus hinausgehen. Prüfen Sie eine schwankende Verbindung, einen Abbruch während der Übertragung, erzwungenes Schließen und Neustarten, zu wenig Speicherplatz, abgelaufene Sitzungen, langsame Wiederverbindungen und gleichzeitige Änderungen auf mehreren Geräten. Stellen Sie sicher, dass gespeicherte Arbeit erhalten bleibt, keine Duplikate entstehen und Konflikte nach der festgelegten Regel behandelt werden.
Legen Sie vor der Veröffentlichung überprüfbare Kriterien fest: Welche Aufgaben funktionieren ohne Netz? Welche Daten dürfen veraltet sein? Wie viele ausstehende Änderungen sind vertretbar? Wie werden Synchronisierungsfehler erkannt, und wer bearbeitet Fälle, die eine Prüfung erfordern? Beobachten Sie nach der Veröffentlichung Synchronisierungsfehler und abgebrochene Aufgaben mit Augenmaß, ohne mehr lokale Informationen als nötig zu erfassen.
Die beste Offline-Strategie macht nicht möglichst viele Funktionen verfügbar: Sie hält wichtige Arbeit unter klaren Bedingungen aufrecht, schützt Daten und ermöglicht es, jede Änderung verlässlich wiederherzustellen. Wenn eine Aufgabe weder mit veralteten Informationen ausgeführt noch vor der erneuten Verbindung bestätigt werden kann, ist ein gut erklärter eingeschränkter Modus möglicherweise das bessere Produkt als ein scheinbar vollständiges Offline-Erlebnis.