Servus! > Hallo Matthias, > > man muss mit den möglichen Usecases anfangen, und klassifizieren, welche man anbieten will und welche nicht. Business Analysis heißt das. Programmierer tun sich schwer damit, wir neigen zum einfach mal losgaloppieren, deshalb hat man in der IT zumeist eigene Leute dafür. Und dann die Requirement Engineers, die das BA Ergebnis für Leute wie dich und mich verständlich machen. > > Wir haben von Mr. Password keine BA bekommen und deshalb schwimmen wir jetzt. Ja. Nein. Mein (kostenloses) Beispiel soll jetzt auch keine umfassende Komplettlösung für ein von Dritten gegen Geld programmiertes Backend sein. --------------- > > Für ein Wiki-Beispiel sollten die Business-Anforderungen minimal sein. Ich bin vor ein paar Wochen auf * [**Formulare/Benutzereingaben zugänglich gestalten**](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten) gestoßen. Das [ehemalige EinzelTutorial "Beschriftungen" ](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten#toc) habe ich um mehrere placeholder-Beispiele bereinigt und dort integriert. Der Abschnitt **"Mehrteilige Formulare"** besteht aus einem Beispiel für fieldset, einem zu progress und zwei multistep-Tutorials [^3], die beide eben noch nicht multistep sind: [^3]: Mein Lastenheft: 1x mit Ausgrauen, 1x mit Einblenden des aktuellen fieldsets - Änderung von title , h2 und `aria-current="step"` 1x mit progress, 1x mit divs als bullet points 1. [Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html) 2. [Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html) (Umfrage) Was ich zusätzlich noch haben wollte (dort oder woanders), wäre ein Formular, in das man eben immer nur einen Datensatz eingibt und dann eine weitere Zeile mit leeren Eingabefeldern erzeugt werden kann.[^1] [^1]: Die Frage ist, ob man so etwas in einem „Anfänger“-Tutorial oder in einem Tutorial „Formulare mit JS – nur für Fortgeschrittene“ behandelt. Ein Tutorial, das sich nur auf die HTML-Elemente an sich konzentriert, würde heute imho nicht mehr ausreichen. Selbst der Einstieg [Was ist ein Webformular?](https://wiki.selfhtml.org/wiki/Formulare/Was_ist_ein_Webformular%3F) verwendet JavaScript. Im Folgekapitel [**Formulare/Auswahllisten**](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#Checkboxen) [^2] gibt es mehrere Beispiele mit Pizza: 3. [Beispiel:Radio vs Checkboxen](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:HTML_input-Element9.html) [^2]: Dort gibt es einen [FlipFlop-Schalter](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#FlipFlop-Schalter), der mit dem Checkbox-Hack arbeitet, vor dem wir eigentlich warnen. @Hörnchen hat uns ja seinen <toggle-switch> gezeigt, den man bei Web Components erklären könnte. Soll der Flip-Flop-Schalter schon vorher weg? Könnte man das Thema durchgehend verwenden? > Für eine flexible Anmeldeseite, wie Password sie sich vorstellt, sieht das ganz anders aus. Das können wir für ihn nicht lösen. Wir könnten uns einen Ordner voller Anforderungen zusammenbrainstormen. Aber entsteht dabei etwas, was Password brauchen kann? > Ja, ein gutes Tutorial könnte ihm zeigen, dass man Formulare * planen und in fieldsets gliedern muss, * alle Eingabefelder mit label, aber nicht mit placeholder versieht * mit JS schrittweise einblendet. Die passgenaue Umsetzung können wir nicht leisten – da hast du Recht! Herzliche Grüße Matthias Scharwies -- Die Signatur findet sich auf der Rückseite des Beitrags.

Servus! > Hallo Matthias, > > man muss mit den möglichen Usecases anfangen, und klassifizieren, welche man anbieten will und welche nicht. Business Analysis heißt das. Programmierer tun sich schwer damit, wir neigen zum einfach mal losgaloppieren, deshalb hat man in der IT zumeist eigene Leute dafür. Und dann die Requirement Engineers, die das BA Ergebnis für Leute wie dich und mich verständlich machen. > > Wir haben von Mr. Password keine BA bekommen und deshalb schwimmen wir jetzt. Ja. Nein. Mein (kostenloses) Beispiel soll jetzt auch keine umfassende Komplettlösung für ein von Dritten gegen Geld programmiertes Backend sein. --------------- > > Für ein Wiki-Beispiel sollten die Business-Anforderungen minimal sein. Ich bin vor ein paar Wochen auf * [**Formulare/Benutzereingaben zugänglich gestalten**](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten) gestoßen. Das [ehemalige EinzelTutorial "Beschriftungen" ](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten#toc) habe ich um mehrere placeholder-Beispiele bereinigt und dort integriert. Der Abschnitt **"Mehrteilige Formulare"** besteht aus einem Beispiel für fieldset, einem zu progress und zwei multistep-Tutorials [^3], die beide eben noch nicht multistep sind: [^3]: Mein Lastenheft: 1x mit Ausgrauen, 1x mit Einblenden des aktuellen fieldsets - Änderung von title , h2 und `aria-current="step"` 1x mit progress, 1x mit divs als bullet points 1. [Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html) 2. [Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html) (Umfrage) Was ich zusätzlich noch haben wollte (dort oder woanders), wäre ein Formular, in das man eben immer nur einen Datensatz eingibt und dann eine weitere Zeile mit leeren Eingabefeldern erzeugt werden kann.[^1] [^1]: Die Frage ist, ob man so etwas in einem „Anfänger“-Tutorial oder in einem Tutorial „Formulare mit JS – nur für Fortgeschrittene“ behandelt. Ein Tutorial, das sich nur auf die HTML-Elemente an sich konzentriert, würde heute imho nicht mehr ausreichen. Selbst der Einstieg [Was ist ein Webformular?](https://wiki.selfhtml.org/wiki/Formulare/Was_ist_ein_Webformular%3F) verwendet JavaScript. Im Folgekapitel [**Formulare/Auswahllisten**](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#Checkboxen) [^2] gibt es mehrere Beispiele mit Pizza: 3. [Beispiel:Radio vs Checkboxen](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:HTML_input-Element9.html) [^2]: Dort gibt es einen [FlipFlop-Schalter](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#FlipFlop-Schalter), der mit dem Checkbox-Hack arbeitet, vor dem wir eigentlich warnen. @Hörnchen hat uns ja seinen <toggle-switch> gezeigt, den man bei Web Components erklären könnte. Soll der Flip-Flop-Schalter schon vorher weg? Könnte man das Thema durchgehend verwenden? > Für eine flexible Anmeldeseite, wie Password sie sich vorstellt, sieht das ganz anders aus. Das können wir für ihn nicht lösen. Wir könnten uns einen Ordner voller Anforderungen zusammenbrainstormen. Aber entsteht dabei etwas, was Password brauchen kann? > Ja, ein gutes Tutorial könnte ihm zeigen, dass man Formulare * planen und in fieldsets gliedern muss, * alle Eingabefelder mit label, aber nicht mit placeholder versieht * mit JS schrittweise einblendet. Die passgenaue Umsetzung können wir nicht leisten – da hast du Recht! Herzliche Grüße Matthias Scharwies -- Die Signatur findet sich auf der Rückseite des Beitrags.

Servus! > Hallo Matthias, > > man muss mit den möglichen Usecases anfangen, und klassifizieren, welche man anbieten will und welche nicht. Business Analysis heißt das. Programmierer tun sich schwer damit, wir neigen zum einfach mal losgaloppieren, deshalb hat man in der IT zumeist eigene Leute dafür. Und dann die Requirement Engineers, die das BA Ergebnis für Leute wie dich und mich verständlich machen. > > Wir haben von Mr. Password keine BA bekommen und deshalb schwimmen wir jetzt. Ja. Nein. Mein (kostenloses) Beispiel soll jetzt auch keine umfassende Komplettlösung für ein von Dritten gegen Geld programmiertes Backend sein. --------------- > > Für ein Wiki-Beispiel sollten die Business-Anforderungen minimal sein. Ich bin vor ein paar Wochen auf * [**Formulare/Benutzereingaben zugänglich gestalten**](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten) gestoßen. Das [ehemalige EinzelTutorial "Beschriftungen" ](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten#toc) habe ich um mehrere placeholder-Beispiele bereinigt und dort integriert. Der Abschnitt **"Mehrteilige Formulare"** besteht aus einem Beispiel für fieldset, einem zu progress und zwei multistep-Tutorials, die beide eben noch nicht multistep sind: 1. [Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html) 2. [Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html) (Umfrage) Was ich zusätzlich noch haben wollte (dort oder woanders), wäre ein Formular, in das man eben immer nur einen Datensatz eingibt und dann eine weitere Zeile mit leeren Eingabefeldern erzeugt werden kann.[^1] [^1]: Die Frage ist, ob man so etwas in einem „Anfänger“-Tutorial oder in einem Tutorial „Formulare mit JS – nur für Fortgeschrittene“ behandelt. Ein Tutorial, das sich nur auf die HTML-Elemente an sich konzentriert, würde heute imho nicht mehr ausreichen. Selbst der Einstieg [Was ist ein Webformular?](https://wiki.selfhtml.org/wiki/Formulare/Was_ist_ein_Webformular%3F) verwendet JavaScript. Im Folgekapitel [**Formulare/Auswahllisten**](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#Checkboxen) [^2] gibt es mehrere Beispiele mit Pizza: 3. [Beispiel:Radio vs Checkboxen](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:HTML_input-Element9.html) [^2]: Dort gibt es einen [FlipFlop-Schalter](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#FlipFlop-Schalter), der mit dem Checkbox-Hack arbeitet, vor dem wir eigentlich warnen. @Hörnchen hat uns ja seinen <toggle-switch> gezeigt, den man bei Web Components erklären könnte. Soll der Flip-Flop-Schalter schon vorher weg? Könnte man das Thema durchgehend verwenden? > Für eine flexible Anmeldeseite, wie Password sie sich vorstellt, sieht das ganz anders aus. Das können wir für ihn nicht lösen. Wir könnten uns einen Ordner voller Anforderungen zusammenbrainstormen. Aber entsteht dabei etwas, was Password brauchen kann? > Ja, ein gutes Tutorial könnte ihm zeigen, dass man Formulare * planen und in fieldsets gliedern muss, * alle Eingabefelder mit label, aber nicht mit placeholder versieht * mit JS schrittweise einblendet. Die passgenaue Umsetzung können wir nicht leisten – da hast du Recht! Herzliche Grüße Matthias Scharwies -- Die Signatur findet sich auf der Rückseite des Beitrags.

Servus! > Hallo Matthias, > > man muss mit den möglichen Usecases anfangen, und klassifizieren, welche man anbieten will und welche nicht. Business Analysis heißt das. Programmierer tun sich schwer damit, wir neigen zum einfach mal losgaloppieren, deshalb hat man in der IT zumeist eigene Leute dafür. Und dann die Requirement Engineers, die das BA Ergebnis für Leute wie dich und mich verständlich machen. > > Wir haben von Mr. Password keine BA bekommen und deshalb schwimmen wir jetzt. Ja. Nein. Mein (kostenloses) Beispiel soll jetzt auch keine umfassende Komplettlösung für ein von Dritten gegen Geld programmiertes Backend sein. --------------- > > Für ein Wiki-Beispiel sollten die Business-Anforderungen minimal sein. Ich bin vor ein paar Wochen auf * [**Formulare/Benutzereingaben zugänglich gestalten**](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten) gestoßen. Das [ehemalige EinzelTutorial "Beschriftungen" ](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten#toc) habe ich um mehrere placeholder-Beispiele bereinigt und dort integriert. Der Abschnitt **"Mehrteilige Formulare"** besteht aus einem Beispiel für fieldset, einem zu progress und zwei multistep-Tutorials, die beide eben noch nicht multistep sind: 1. [Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html) 2. [Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html) (Umfrage) Was ich zusätzlich noch haben wollte (dort oder woanders), wäre ein Formular, in das man eben immer nur einen Datensatz eingibt und dann eine weitere Zeile mit leeren Eingabefeldern erzeugt werden kann.[^1] [^1]: Die Frage ist, ob man so etwas in einem „Anfänger“-Tutorial oder in einem Tutorial „Formulare mit JS – nur für Fortgeschrittene“ behandelt. Ein Tutorial, das sich nur auf die HTML-Elemente an sich konzentriert, würde heute imho nicht mehr ausreichen. Selbst der Einstieg [Was ist ein Webformular?](https://wiki.selfhtml.org/wiki/Formulare/Was_ist_ein_Webformular%3F) verwendet JavaScript. Im Folgekapitel [**Formulare/Auswahllisten**](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#Checkboxen) gibt es mehrere Beispiele mit Pizza: 3. [Beispiel:Radio vs Checkboxen](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:HTML_input-Element9.html) Könnte man das Thema durchgehend verwenden? > Für eine flexible Anmeldeseite, wie Password sie sich vorstellt, sieht das ganz anders aus. Das können wir für ihn nicht lösen. Wir könnten uns einen Ordner voller Anforderungen zusammenbrainstormen. Aber entsteht dabei etwas, was Password brauchen kann? > Ja, ein gutes Tutorial könnte ihm zeigen, dass man Formulare * planen und in fieldsets gliedern muss, * alle Eingabefelder mit label, aber nicht mit placeholder versieht * mit JS schrittweise einblendet. Die passgenaue Umsetzung können wir nicht leisten – da hast du Recht! Herzliche Grüße Matthias Scharwies -- Die Signatur findet sich auf der Rückseite des Beitrags.

Servus! > Hallo Matthias, > > man muss mit den möglichen Usecases anfangen, und klassifizieren, welche man anbieten will und welche nicht. Business Analysis heißt das. Programmierer tun sich schwer damit, wir neigen zum einfach mal losgaloppieren, deshalb hat man in der IT zumeist eigene Leute dafür. Und dann die Requirement Engineers, die das BA Ergebnis für Leute wie dich und mich verständlich machen. > > Wir haben von Mr. Password keine BA bekommen und deshalb schwimmen wir jetzt. Ja. Nein. Mein (kostenloses) Beispiel soll jetzt auch keine umfassende Komplettlösung für ein von Dritten gegen Geld programmiertes Backend sein. --------------- > > Für ein Wiki-Beispiel sollten die Business-Anforderungen minimal sein. Ich bin vor ein paar Wochen auf * [**Formulare/Benutzereingaben zugänglich gestalten**](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten) gestoßen. Das [ehemalige EinzelTutorial "Beschriftungen" ](https://wiki.selfhtml.org/wiki/Formulare/Benutzereingaben_zug%C3%A4nglich_gestalten#toc) habe ich um mehrere placeholder-Beispiele bereinigt und dort integriert. Der Abschnitt **"Mehrteilige Formulare"** besteht aus einem Beispiel für fieldset, einem zu progress und zwei multistep-Tutorials, die beide eben noch nicht multistep sind: 1. [Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Bestellformular_mit_verschiedenen_Abschnitten.html) 2. [Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:Klassen_mit_JavaScript_umschalten_und_mit_CSS_nutzen2.html) (Umfrage) Was ich zusätzlich noch haben wollte (dort oder woanders), wäre ein Formular, in das man eben immer nur einen Datensatz eingibt und dann eine weitere Zeile mit leeren Eingabefeldern erzeugt werden kann. Im Folgekapitel [**Formulare/Auswahllisten**](https://wiki.selfhtml.org/wiki/Formulare/Auswahllisten#Checkboxen) gibt es mehrere Beispiele mit Pizza: 3. [Beispiel:Radio vs Checkboxen](https://wiki.selfhtml.org/extensions/Selfhtml/example.php/Beispiel:HTML_input-Element9.html) Könnte man das Thema durchgehend verwenden? > Für eine flexible Anmeldeseite, wie Password sie sich vorstellt, sieht das ganz anders aus. Das können wir für ihn nicht lösen. Wir könnten uns einen Ordner voller Anforderungen zusammenbrainstormen. Aber entsteht dabei etwas, was Password brauchen kann? > Ja, ein gutes Tutorial könnte ihm zeigen, dass man Formulare * planen und in fieldsets gliedern muss, * alle Eingabefelder mit label, aber nicht mit placeholder versieht * mit JS schrittweise einblendet. Die passgenaue Umsetzung können wir nicht leisten – da hast du Recht! Herzliche Grüße Matthias Scharwies -- Die Signatur findet sich auf der Rückseite des Beitrags.