Hallo.
Kann es nicht sein, dass ein Pflichtfeld leer bleiben kann, aber
der User diese Leere als relevanten Inhalt eines Pflichtfeldes sendet
und damit die Verarbeitung dieses Feldes wünscht?
Eine Vorbelegung mit "[leer]" oder "Keine Angaben" ist ja möglich., was die Notwendigkeit gegen Null tendieren lässt. Und eine Nichteingabe vielleicht sogar verpflichtend zu machen, halte ich für nicht intuitiv. Wozu dann ein Eingabefeld?
Wir sehen dass da praktisch Nuancen sind.
--Ein leeres Feld soll in die Verarbeitung einbezogen werden
--Ein leeres Feld soll gar nicht gesendet und in die Verarbeitung einbezogen werden.
Praktisch kommt in beiden Fällen kein Wert für das Feld an. Nicht sehr geschickt.
Es sind zwei verschiedene Dinge zu sagen:
Nickname:
Dies ist ein Pflichtfeld.
Nickname:
Ihr Nickname darf nicht leer sein. Er muss aus den Zeichen .... bestehen.
oder
Nickname:
Ihr Nickname muss aus den Zeichen .... bestehen.
Wenn Sie den Namen nicht angeben, wird er aus den Felder Name und Vorname zusammengesetzt.
Ein gutes Formular könnte den Nick bereits während der Eingabe von Name und Vorname generieren, weitere Änderungen zulassen und nur darauf bestehen, nicht leer abgeschickt zu werden.
Der Begriff Pflichtfeld sagt mir bisher nur eines:
Der User muss sich mit dem Feld auseinandersetzen.
Aber es besagt noch nicht, dass er etwas eintragen muss.
Auseinandersetzen muss sich der Nutzer mit jedem Feld, denn es könnte sich ja auf die Verarbeitung der übrigen Angaben auswirken.
Und dass Pflichtfelder per Definition auszufüllen sind, kann wohl als Common Sense angesehen werden.
Sollte ein leeres Feld gesendet werden, kann dies nur mit Umweg realisiert werden.
[X] leeres Feld senden.
<input type=checkbox name="feld_x_ist_leer">
Eine einfache Vorbelegung des leeren Feldes wäre hier doch völlig ausreichend.
Auch das wäre ja möglich. Man könnte mit jedem Eintrag das nächste Feld freigeben, obwohl man von Anfang an alles sieht. Und sobald dann die wirklichen Pflichtfelder ausgefüllt sind, wird der gesamte Rest freigegeben.
Das ist Theorie, die im jetzigen HTML leider noch nicht diskutiert werden braucht.
Über das "leider" ließe sich auch wieder diskutieren, aber von nacktem HTML war ich nicht ausgegangen.
Ich möchte Java-Script nicht als Basis nehmen.
Ich schon, und ohne gibt es das Standard-Formular.
Praktisch wirst du also ein zweistufiges Prozedere machen müssen.
Praktisch halte ich eine einstufige klassische Fallback-Lösung für angebrachter. Denn ein Formular praktisch zweimal abschicken zu müssen, irritiert meines Erachtens unnötig und kann zur Fehlbedienung führen, wenn man meint, ja bereits alles wichtige ausgefüllt und abgesandt zu haben, und daraufhin die Seite schließt.
Ein Loginformular soll sich auf notwendige Angaben beschränken.
Definitiv.
Ich wüsste nicht, welche später nützliche Daten hier unmittelbar zu einer unmittelbaren Validierung assistieren könnten (z.B. Adresse, Telefon etc...)
Hier steht der user in der Regel wenigen Feldern gegenüber.
Wozu ein Passwort angeben, wenn es schon den Namen in dieser Schreibweise nicht gibt? Gehört das Passwort zu den notwendigen Angaben, wenn der Name nicht stimmt?
Anders sieht es aus, wenn es um ein Userprofil geht. Es handelt sich hier um eine Art Design, und ein User kann seine Entscheidung mehrfach revidieren.
Warum soll ihm hier eine Reihenfolge aufgebürdet werden?
Bereits meine allererste Aussage zu diesem Thema begann mit der Feststellung, dass ich mir nur wenige Einsatzfälle für diese Technik vorstellen kann. Du kannst natürlich gern noch die eine oder andere Handvoll weiterer Beispiele für die Nichtanwendbarkeit heraussuchen, aber irgendwie ist das witzlos.
Für Non-Screen Medien gelten hier bestimmt noch andere Überlegungen.
Was sind Non-Screen-Medien für dich? Andere interaktive Medien könnten letztlich ähnlich funktionieren, oder welche Besonderheiten schweben dir vor?
Und die Version auf totem Holz können wir ja außen vor lassen. Die ist ja inzwischen so gut, dass es da kaum noch etwas zu verbessern gibt -- außer ihrer Verbreitung im Vergleich zu ihren Vorgängern natürlich.
MfG, at