"Durchklick" Formular

[Maik Franz]

Hallo,

Auf der Seite codingarts habe ich ein, ich nenne es mal durchklick Formular gefunden, wo man Fragen gestellt bekommt und mit einem Klick auf eine Antwort zur nächsten Frage kommt. Jetzt meine Frage: Wie schafft man so etwas, dass es auch ein Laie wie ich versteht?

Mit freundlichen Grüßen,

Maik Franz

[Gunnar Bittersmann]

@@Maik Franz

Hallo,

Auf der Seite codingarts

Oh je, „Überzeugendes Webdesign“ obendrüber schreiben und nicht einmal die eigene Website hinbekommen. Mit Tastatur gehr da gar nichts.

Und Code aus der Hölle …

habe ich ein, ich nenne es mal durchklick Formular gefunden, wo man Fragen gestellt bekommt und mit einem Klick auf eine Antwort zur nächsten Frage kommt.

Im action-Attribut des formulars steht der URL zum serverseitigen Script, das die Eingaben entgegennimmt und die nächste Seite erstellt.

LLAP 🖖

[encoder]

Oh je, „Überzeugendes Webdesign“ obendrüber schreiben und nicht einmal die eigene Website hinbekommen. Mit Tastatur gehr da gar nichts.

Und das Komma im Preis für einen "one pager" haben sie auch vergessen. Oder ist das realistisch?

[Maik Franz]

Also, wenn ich das jetzt richtig verstanden habe, kann ich das ganze nicht mit der Tastatur "programmieren". Frage ist nur: Wie sonst? Fand das ganze nur sehr interessant und würde es gerne selber auf meiner Seite einbauen.

Mfg

[Matthias Apsel]

Hallo Maik Franz,

Also, wenn ich das jetzt richtig verstanden habe, kann ich das ganze nicht mit der Tastatur "programmieren". Frage ist nur: Wie sonst? Fand das ganze nur sehr interessant und würde es gerne selber auf meiner Seite einbauen.

Gemeint ist, dass das Formular nicht mit der Tastatur bedienbar ist. Das ist schlecht.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Gemeint ist, dass das Formular nicht mit der Tastatur bedienbar ist.

Doch, isses, wenn man sich denn erst einmal durch die Leere dahin getabbt hat.

Allerdings weiß man dann nicht so recht, was man in die Felder eintragen soll, da diese keine Beschriftung haben. (Beschriftung meint nicht, dass etwas lediglich visuell in der Nähe des Eingabefeldes steht, sondern ein label-Element.)

Das ist schlecht.

Ja, das isses.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Gemeint ist, dass das Formular nicht mit der Tastatur bedienbar ist.

Doch, isses,

Ach, ich hatte gemeint, deine Kritik bezöge sich auf das Formular. Ich hab mir weder die Seite, noch das Formular angeschaut, nur deine Aussage übersetzt. 😂

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Ich hab mir weder die Seite, noch das Formular angeschaut

Besser ist auch.

Ein Stückchen HTML/DOM hast du dir aber angeschaut, das weiß ich. ❤️

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ein Stückchen HTML/DOM hast du dir aber angeschaut, das weiß ich. ❤️

Aber nur als Foto.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Ein Stückchen HTML/DOM hast du dir aber angeschaut, das weiß ich. ❤️

Aber nur als Foto.

Mit Alternativtext, selbstverständlich.

LLAP 🖖

[Gunnar Bittersmann]

@@Maik Franz

Also, wenn ich das jetzt richtig verstanden habe, kann ich das ganze nicht mit der Tastatur "programmieren".

Nein, was ich sagte war, dass die Website dieser Agentur nicht per Tastatur bedienbar ist. Weil sie die browsereigene Kennzeichnung des fokussierten Elements gedankenlos entfernt haben und dann vergessen haben, im Menü den :hover-Effekt auch für :focus vorzusehen. Oder gar nicht gewusst, dass man das überhaupt tun muss. Eins ist für eine Webagentur so schlecht wie das andere.

Aber sich selbst zum „Proven Expert“ küren. Ach du Scheiße …

LLAP 🖖

[Maik Franz]

Jetzt weiß ich, dass die Seite schlecht ist, die Idee finde ich allerdings immer noch gut. Die Antwort auf die Frage wie es denn nu gehen könnte, würde mich erfreuen und bitte so, dass es einer der nicht ganz so viel Ahnung mit css etc. hat. Danke😀

Vg

[Gunnar Bittersmann]

@@Maik Franz

Die Antwort auf die Frage wie es denn nu gehen könnte, würde mich erfreuen

Du hattest bereits Grund zur Freude.

LLAP 🖖

[pl]

@Gunnar Bittersmann

Im action-Attribut des formulars steht der URL zum serverseitigen Script, das die Eingaben entgegennimmt und die nächste Seite erstellt.

Warum sollte im action-Attribut ein anderer URL stehen als derjenige der zur aktuellen Seite gehört?

MfG

[Gunnar Bittersmann]

@@pl

Im action-Attribut des formulars steht der URL zum serverseitigen Script, das die Eingaben entgegennimmt und die nächste Seite erstellt.

Warum sollte im action-Attribut ein anderer URL stehen als derjenige der zur aktuellen Seite gehört?

Wegen „Formular, wo man Fragen gestellt bekommt und mit einem Klick auf eine Antwort zur nächsten Frage kommt.“

LLAP 🖖

[pl]

@Gunnar Bittersmann

Im action-Attribut des formulars steht der URL zum serverseitigen Script, das die Eingaben entgegennimmt und die nächste Seite erstellt.

Warum sollte im action-Attribut ein anderer URL stehen als derjenige der zur aktuellen Seite gehört?

Wegen „Formular, wo man Fragen gestellt bekommt und mit einem Klick auf eine Antwort zur nächsten Frage kommt.“

Das ist keine Begründung. Warum sollte denn die Antwort an einen anderen URL gesendet werden als an denjenigen der die Frage geliefert hat? Das ergibt ja überhaupt keinen Sinn. MfG

[Gunnar Bittersmann]

@@pl

Das ist keine Begründung.

Dass du die Begründung nicht verstehst heißt nicht, dass es keine ist.

Warum sollte denn die Antwort an einen anderen URL gesendet werden als an denjenigen der die Frage geliefert hat? Das ergibt ja überhaupt keinen Sinn.

Von Affenformularen mal abgesehen ist es durchaus üblich, Formulare an eine andere Adresse zur Auswertung zu schicken.

Dass du den Sinn nicht verstehst heißt nicht, dass es keinen ergibt.

LLAP 🖖

[encoder]

Die URL liefert ja keine Frage auf die sie eine Antwort will. Sie liefert die Möglichkeit etwas einzugeben und das irgendwo hin zu schicken.
Als man anfangs noch html Seiten erstellt hat (statt dynamischem Zeug) war das so üblich. Eine statische *.html Seite hat ihr Formular an ein pl pder php Script oder sonstiges übergeben.
Auch sonst gibt es sicher Gründe um irgendetwas an eine andere Seite oder Domain übergeben zu wollen.

[pl]

Es braucht einen Ablaufplan zur Konfiguration in welcher die einzelnen Schritte definiert sind. Schritt 1 will z.B. name als input, Schritt 2 kriegt name aus einem hiddenfield und will vorname als nächsten input usw. Am Ende liegen alle bereits getätigten Eingaben in hidden-fields wo sie also von einem Submit zum nächsten akkumuliert werden. Gesteuert wird das über einen Schlüsselparameter step=1, step=2 usw. Serverseitig wird anhand der Konfiguration auch geprüft, ob die erforderlichen Daten eingegeben wurden. Alternativ zu hiddenfields kann man die Eingaben auch in der Session akkumulieren. MfG

[Felix Riesterer]

Lieber Maik,

Formular gefunden, wo man Fragen gestellt bekommt und mit einem Klick auf eine Antwort zur nächsten Frage kommt. Jetzt meine Frage: Wie schafft man so etwas, dass es auch ein Laie wie ich versteht?

es braucht ein serverseitiges Script, welches die übermittelten Formulardaten auswertet. Ein solches ist entweder in serverseitigem Java, oder eben in einer anderen serverseitigen Scriptspache wie Perl, PHP, Ruby und dergleichen geschrieben.

Das serverseitige Script kennt den Ablauf, auf welche Eingaben hin welches nächste Formular an den Browser verschickt wird, damit der Seitenbesucher die nächsten Eingaben vornehmen kann. Auf diese Weise können nicht-lineare Verläufe abgearbeitet werden ("Sie sind also Veganer, möchten Sie lieber Tofu oder Kichererbsen als Proteinliefernaten?").

Mit JavaScript kann man im Browser mehrteilige Formulare mit einem "Durchblätter-Effekt" versehen, der einen ähnlichen Mechanismus suggeriert. Das bedeutet, dass bei nicht-linearen Verläufen die JavaScript-Logik ebenso wie die oben angesprochene serverseitige Logik den Benutzer an die Hand nehmen kann, um nicht benötigte Formularteile ("falls Sie mit 'nein' antworten, sind die nächsten drei Punkte gegenstandslos") auszublenden.

Eine Lösung, die auf JavaScript setzt, hat wie immer das Problem, dass sie, falls JavaScript beim Client aus irgendwelchen Gründen nicht verfügbar ist, so gestaltet sein muss, dass die Seite auch ohne JavaScript vollauf bedienbar sein muss. So gesehen wäre eine serverseitige Lösung "stabiler", da die "Benutzerführung" unter allen Umständen gegeben ist.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

Eine Lösung, die auf JavaScript setzt, hat wie immer das Problem, dass sie, falls JavaScript beim Client aus irgendwelchen Gründen nicht verfügbar ist, so gestaltet sein muss, dass die Seite auch ohne JavaScript vollauf bedienbar sein muss.

Wobei „falls JavaScript nicht verfügbar ist“ auch heißen kann „falls dieses JavaScript nicht verfügbar ist“. – Es geht ja nicht nur um Nutzer, die JavaScript deaktivieren, sondern dass dieses JavaScript aus irgendwelchen Gründen nicht verfügbar sein mag.

So gesehen wäre eine serverseitige Lösung "stabiler", da die "Benutzerführung" unter allen Umständen gegeben ist.

Aber auch langsamer, da man bei jedem Schritt die Eingabe zum Server sendet und auf dessen Antwort warten muss. Im für den Nutzer besten Fall implementiert man also beides: serverseitige Verarbeitung als Grundlage, clientseitige Verarbeitung als progressive enhancement.

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

Wobei „falls JavaScript nicht verfügbar ist“ auch heißen kann „falls dieses JavaScript nicht verfügbar ist“.

ich hatte IceCat mobile ausprobiert und mühsam herausfinden müssen, dass die vorinstallierten Add-Ons "unfreie JavaScripte" blockierten. Auch die von der Seite selbst hinterlegten. Vermutlich suchen die Add-Ons im Quelltext nach Hinweisen auf entsprechende Lizenzen, aber damit war die JavaScript-Funktionalität erst einmal wirkungsvoll weg.

Anstatt in alle meine JavaScripte irgendein Geschwafel über die GPL einzufügen habe ich schlicht die Add-Ons deaktiviert. Soviel zum Sinn ungefragt vorinstallierter Add-Ons.

Liebe Grüße,

Felix Riesterer.

[pl]

hi,

Das serverseitige Script kennt den Ablauf, auf welche Eingaben hin welches nächste Formular an den Browser verschickt wird, damit der Seitenbesucher die nächsten Eingaben vornehmen kann. Auf diese Weise können nicht-lineare Verläufe abgearbeitet werden ("Sie sind also Veganer, möchten Sie lieber Tofu oder Kichererbsen als Proteinliefernaten?").

Idealerweise wird der Ablauf einschließlich aller möglichen Verzweigungen außerhalb vom Code zentral konfiguriert.

Mit JavaScript kann man im Browser mehrteilige Formulare mit einem "Durchblätter-Effekt" versehen, der einen ähnlichen Mechanismus suggeriert. Das bedeutet, dass bei nicht-linearen Verläufen die JavaScript-Logik ebenso wie die oben angesprochene serverseitige Logik..

Wenn die Ablauf-Logik serverseitig konfiguriert wurde, kommt JavaScript allenfalls die Aufgabe der Datenübermittlung zu (xhr, fetch). Ebenso werden etwaige Fehlermeldungen und Dialoge die sich serverseitig ergeben, von JS nur durchgereicht, so daß der Benutzer eine Entscheidung treffen kann.

Den Ablaufplan sowohl server- als auch clientseitig vorzuhalten erschwert die Wartung und Pflege der Anwendung.

MfG

[Gunnar Bittersmann]

@@pl

Den Ablaufplan sowohl server- als auch clientseitig vorzuhalten erschwert die Wartung und Pflege der Anwendung.

Inwiefern sollte das so sein, wenn der Ablaufplan in JSON vorliegt?

LLAP 🖖

[pl]

@Gunnar Bittersmann

Den Ablaufplan sowohl server- als auch clientseitig vorzuhalten erschwert die Wartung und Pflege der Anwendung.

Inwiefern sollte das so sein, wenn der Ablaufplan in JSON vorliegt?

Inwiefern sollte ein Ablaufplan in JSON vorliegen? MfG

[Gunnar Bittersmann]

@@pl

Den Ablaufplan sowohl server- als auch clientseitig vorzuhalten erschwert die Wartung und Pflege der Anwendung.

Inwiefern sollte das so sein, wenn der Ablaufplan in JSON vorliegt?

Inwiefern sollte ein Ablaufplan in JSON vorliegen?

Um zu vermeiden, dass den Ablaufplan sowohl server- als auch clientseitig vorzuhalten die Wartung und Pflege der Anwendung erschwert.

Es spricht wohl nichts dagegen, dafür JSON einzusetzen; das kann sowohl server- als auch clientseitig von der jeweiligen Programmierprache einfach geparst werden.

LLAP 🖖

[pl]

@Gunnar Bittersmann

Den Ablaufplan sowohl server- als auch clientseitig vorzuhalten erschwert die Wartung und Pflege der Anwendung.

Inwiefern sollte das so sein, wenn der Ablaufplan in JSON vorliegt?

Inwiefern sollte ein Ablaufplan in JSON vorliegen?

Um zu vermeiden, dass den Ablaufplan sowohl server- als auch clientseitig vorzuhalten die Wartung und Pflege der Anwendung erschwert.

Das Eine hat doch mit dem Anderen nichts zu tun.

Es spricht wohl nichts dagegen, dafür JSON einzusetzen; das kann sowohl server- als auch clientseitig von der jeweiligen Programmierprache einfach geparst werden.

Dafür aber auch nicht. In welcher Form ein Ablaufplan serverseitig persistent gemacht wird, ist völlig nebensächlich, dafür gibt es Data Access Layer. Und in welcher Form der Plan zum Client kommt, ist genauso nebensächlich, dafür gibt es Data Transport Layer.

Ergo muss ein Ablaufplan mitnichten in JSON vorliegen. MfG

[Gunnar Bittersmann]

@@pl

Ergo muss ein Ablaufplan mitnichten in JSON vorliegen.

Das hat auch niemand behauptet.

LLAP 🖖