Zum Hauptinhalt springen
← Alle Beiträge

M48 Entwicklungspraxis

So gestalten Sie ein Antragsformular, das eingegebene Daten nicht verliert

Ein praktischer Leitfaden zum Erstellen von Antragsformularen, die Benutzereingaben bei Unterbrechungen bewahren – inklusive Validierung, lokaler Speicherung, serverseitigen Fallbacks und einer Checkliste vor dem Launch.

M48 Editorial5 MinutenAktualisiert:

Warum Formulare Daten verlieren

Benutzer brechen Antragsformulare aus vielen Gründen ab: Ein Browser-Tab schließt sich versehentlich, ein Netzwerkfehler unterbricht die Übermittlung oder ein Validierungsfehler löscht bereits ausgefüllte Felder. Wenn das passiert, sind die Kosten nicht nur Frustration. Jeder verlorene Eintrag ist eine verpasste Anfrage, und wiederholte Versuche brechen oft vollständig ab. Ein Formular, das Eingaben bewahrt, respektiert die Zeit des Nutzers und schützt Ihre Pipeline.

Entscheidungskriterien vor dem Bau

Wählen Sie Ihre Speicherstrategie basierend auf drei Faktoren: Formularlänge, Datenempfindlichkeit und Übermittlungskritikalität. Ein kurzes Newsletter-Anmeldeformular benötigt weniger Schutz als ein mehrseitiges Bewerbungsformular. Wenn das Formular persönliche Kennungen, Finanzdaten oder Dokumente sammelt, reicht clientseitige Speicherung allein nicht aus; Sie benötigen serverseitige Entwürfe mit Verschlüsselung im Ruhezustand und während der Übertragung. Bei geringriskigen Anfragen reicht möglicherweise eine browserbasierte Autosave-Funktion. Bewerten Sie das Risiko zuerst, und wählen Sie dann den technischen Ansatz.

Implementierungsschritte

Beginnen Sie mit progressiver Verbesserung. Erstellen Sie ein einfaches HTML-Formular, das auch ohne JavaScript funktioniert, und legen Sie dann Verbesserungen darauf. Verwenden Sie das autocomplete-Attribut bei jedem Eingabefeld, damit Browser zuvor eingegebene Werte vorschlagen können. Fügen Sie required- und pattern-Attribute für grundlegende clientseitige Validierung hinzu, verlassen Sie sich aber niemals ausschließlich darauf als einzige Schutzmaßnahme.

Als Nächstes implementieren Sie die lokale Entwurfsspeicherung. Wenn ein Benutzer in ein Feld tippt, schreiben Sie den Wert in den browserseitigen localStorage oder IndexedDB, keyed durch eine stabile Formularkennung. Beim Laden der Seite prüfen Sie, ob ein gespeicherter Entwurf vorhanden ist, und füllen die Felder automatisch erneut aus. Löschen Sie den Entwurf erst nach einer erfolgreichen Serverübermittlung oder wenn der Benutzer das Formular explizit zurücksetzt. Dies schützt vor versehentlichem Aktualisieren und geschlossenen Tabs.

Bei längeren Formularen speichern Sie Entwürfe in regelmäßigen Abständen oder beim Verlassen eines Feldes (blur) auf dem Server. Senden Sie nur die geänderten Felder in einer leichten Anfrage und speichern Sie die Nutzlast, verknüpft mit einem anonymen Sitzungstoken oder einem authentisierten Benutzerkonto. Wenn der Benutzer zurückkehrt, rufen Sie den Entwurf ab und führen ihn mit den aktuellen Formularwerten zusammen. Dieser Ansatz übersteht Gerätewechsel und Browserleerungen, bringt jedoch Datenschutzaspekte mit sich.

Gehen Sie sorgfältig mit Validierung um. Zeigen Sie Inline-Fehler direkt neben dem betreffenden Feld an, anstatt eine generische Nachricht oben auf der Seite. Bewahren Sie alle anderen eingegebenen Werte auf, wenn ein Fehler auftritt. Löschen Sie das Formular bei fehlgeschlagener Übermittlung nicht; führen Sie den Benutzer zurück zur gleichen Seite mit intakten Daten und markieren Sie genau, was korrigiert werden muss.

Fügen Sie einen klaren Absendebutton-Zustand hinzu. Deaktivieren Sie den Button während der Übermittlung, um doppelte Posts zu verhindern, aktivieren Sie ihn jedoch erneut, wenn die Anfrage fehlschlägt, damit der Benutzer erneut versuchen kann, ohne Daten neu einzugeben. Geben Sie eine Erfolgsmeldung aus, die den Empfang bestätigt und die nächsten Schritte erklärt.

Häufige Fehler und wie Sie sie vermeiden

Ein häufiger Fehler ist das Speichern sensibler Daten im Klartext in localStorage. Jedes Skript, das auf der Seite ausgeführt wird, kann es lesen, was gefährlich für persönliche oder finanzielle Informationen ist. Hypothetisch: Wenn ein Bewerbungsformular eine nationale ID-Nummer in localStorage speichern würde und ein Drittanbieter-Widget kompromittiert würde, könnte diese Kennung offengelegt werden. Speichern Sie sensible Felder nicht clientseitig; halten Sie sie in serverseitigen Entwürfen mit Zugriffskontrollen.

Ein weiterer Fehler sind stille Entwurfüberschreibungen. Wenn ein Benutzer dasselbe Formular in zwei Tabs öffnet und in einem speichert, kann der andere Tab veraltete Daten laden und neuere Einträge beim Aktualisieren überschreiben. Verwenden Sie einen Zeitstempel der letzten Änderung oder ein Versionsflag, um Konflikte zu erkennen, und warnen Sie den Benutzer, bevor Sie einen neueren Entwurf ersetzen.

Das Löschen von localStorage beim Ausloggen ist ebenfalls problematisch. Wenn ein angemeldeter Benutzer einen Entwurf speichert und sich dann ausloggt, kann der Entwurf verschwinden, wenn er nur an die Sitzung gebunden ist. Halten Sie anonyme Entwürfe von authentifizierten Sitzungen getrennt oder fordern Sie den Benutzer auf, den Entwurf vor dem Ausloggen zu speichern oder zu verwerfen.

Verwechseln Sie schließlich nicht Browser-Autovervollständigung mit Formularspeicherung. Autovervollständigung hilft zurückkehrenden Nutzern, bekannte Werte auszufüllen, rekonstruiert aber kein teilweise ausgefülltes Formular nach einem Absturz. Behandeln Sie sie als ergänzend, nicht als austauschbar.

Datenschutzmaßnahmen

Behandeln Sie ungespeicherte Entwürfe als personenbezogene Daten. Begrenzen Sie, wie lange Entwürfe auf dem Server verbleiben, und löschen Sie sie automatisch nach einem definierten Aufbewahrungszeitraum. Entwürfe, die Dateiuploads enthalten, sollten Verweise, nicht die Dateien selbst speichern, bis zur endgültigen Übermittlung. Verwenden Sie HTTPS für alle Entwurfsanfragen und wenden Sie dieselben Authentifizierungs- und Autorisierungsregeln an wie für eingereichte Anträge.

Wenn Sie Cookies zur Verfolgung von Entwurfskennungen verwenden, setzen Sie die Attribute HttpOnly und SameSite, um die Exposition zu reduzieren. Protokollieren Sie Entwurfsinhalte nicht in Analyseplattformen, es sei denn, Sie haben eine klare rechtliche Grundlage und die Zustimmung des Nutzers. Führen Sie ein Verzeichnis darüber, welche Daten gesammelt werden, wo sie gespeichert sind und wann sie gelöscht werden.

Checkliste vor dem Launch

  • [ ] Das Formular funktioniert ohne JavaScript für die grundlegende Übermittlung
  • [ ] Jedes Eingabefeld hat ein entsprechendes autocomplete-Attribut
  • [ ] Entwürfe speichern in localStorage oder IndexedDB bei Eingabe
  • [ ] Entwürfe werden beim Laden der Seite nach versehentlichem Schließen wiederhergestellt
  • [ ] Serverseitiger Entwurfsendpunkt existiert für mehrstufige oder lange Formulare
  • [ ] Validierungsfehler bewahren alle eingegebenen Werte
  • [ ] Absendebutton deaktiviert während der Anfrage und aktiviert sich erneut bei Fehler
  • [ ] Sensible Felder werden nicht im Klartext clientseitig gespeichert
  • [ ] Aufbewahrungs- und Löschzeitplan für Entwürfe ist definiert
  • [ ] Alle Entwurfsdatenübertragungen verwenden HTTPS

Der Start eines Formulars ohne diese Schutzmaßnahmen birgt das Risiko, echte Anfragen zu verlieren. Ein gut geschütztes Formular hält Benutzereingaben sicher, reduziert Abbrüche und macht jeden Besuch wahrscheinlicher, in einer abgeschlossenen Übermittlung zu enden.

Ihr Projekt besprechen

Verwandte Leistungen

Bereit, Ihr Projekt zu starten?

Lassen Sie uns besprechen, wie wir Ihre Vision zum Leben erwecken können

Kostenlose Projektanalyse starten ↗