Zeigt her Eure Formulare

[hotti]

Liebe Leute,

ungezählte Webanwendungen habe ich programmiert die erstklassig funktionieren, aber besonders schön sind die nicht, weil: Ich bin (noch) nicht so der Designer. Deswegen möchte ich mir ein paar ganz besonders schöne Formulare mal anschauen, Ihr habt da bestimmt was zum herzeigen.

Schön heißt: Benutzerfreundlich, responsive, funktional.

Viele Grüße!

[Gunnar Bittersmann]

@@hotti:

nuqneH

ungezählte Webanwendungen habe ich programmiert die erstklassig funktionieren, aber besonders schön sind die nicht, weil: Ich bin (noch) nicht so der Designer.

Nach deiner weiter unten angegebenen Definition von Schönheit „Schön heißt: Benutzerfreundlich, responsive, funktional“ (die ich nicht teile) sagst du:

ungezählte Webanwendungen habe ich programmiert die erstklassig funktionieren, aber besonders benutzerfreundlich, responsive, funktional sind die nicht

Du erkennst den Widerspruch? Von „erstklassig funktionieren“ kann überhaupt keine Rede sein.

„Design ist nicht nur, wie es aussieht und wie es sich anfühlt. Design ist, wie es funktioniert.“ (Steve Jobs)

Qapla'

[hotti]

hi,

Du erkennst den Widerspruch? Von „erstklassig funktionieren“ kann überhaupt keine Rede sein.

„Design ist nicht nur, wie es aussieht und wie es sich anfühlt. Design ist, wie es funktioniert.“ (Steve Jobs)

Widersprüche sind Triebkräfte der Entwicklung (Karl Marx, auch tot).

MfG

[mrjerk]

Moin,

„Design ist nicht nur, wie es aussieht und wie es sich anfühlt. Design ist, wie es funktioniert.“ (Steve Jobs)

Interessant, dass Du das sagst. An der Uni hab ich seinerzeit ein paar Vorlesungen/Seminare über Usability besucht. Dort wurde Design meist als Widerspruch zur Usability gesehen (die "bösen" Designer, die die schöne Benutzbarkeit kaputt machen ;)).

Ich bemerke aber, dass sich in den letzten Jahren offenbar die Bedeutung des Begriffes "Design" in die von Dir angedeutete Richtung ändert - es ist wohl kein Zufall, dass in den letzten Jahren Begriffe wie "User centered Design" aus dem Boden schiessen und dass "Usability-Experten" heute "User Experience-Experten" heissen. Vermutlich ist so langsam angekommen, dass Design und Usability eine Einheit bilden müssen, und nicht zwei konkurierende Optimierungsziele sind (bzw. sein sollten).

Nur ein paar Gedanken zum Samstag :)

Viele Grüße,
Jörg

[Gunnar Bittersmann]

@@mrjerk:

nuqneH

dass "Usability-Experten" heute "User Experience-Experten" heissen.

Nö, da kann man durchaus trennen. Leute, die sich mit Messungen zur Usability mit Eye-Tracking etc. befassen, sind nicht (unbedingt) UX-Experten.

Allerdings hat sich die UPA in UXPA umbenannt (auch wenn die Wikipedia noch die alte Bezeichnung in der Überschrift führt). Die German UPA heißt immer noch so.

Vermutlich ist so langsam angekommen, dass Design und Usability eine Einheit bilden müssen, und nicht zwei konkurierende Optimierungsziele sind (bzw. sein sollten).

Wir sind auf gutem Wege.

Qapla'

[tami]

hi hotti,

ungezählte Webanwendungen habe ich programmiert die erstklassig funktionieren, aber besonders schön sind die nicht, weil: Ich bin (noch) nicht so der Designer. Deswegen möchte ich mir ein paar ganz besonders schöne Formulare mal anschauen, Ihr habt da bestimmt was zum herzeigen.

Schön heißt: Benutzerfreundlich, responsive, funktional.

https://www.google.de/search?q=formulare+design+css

mfg

tami

[hotti]

hi,

https://www.google.de/search?q=formulare+design+css

Ja, da habe ich auch schon sehr schöne Formulare gefunden. Machst Du auch welche? Zeig mal.

Horst Formlos

[tami]

hi hotti,

Ja, da habe ich auch schon sehr schöne Formulare gefunden. Machst Du auch welche? Zeig mal.

Nee, ich nix Design ;-).

mfg

tami

[1UnitedPower]

Meine Herren!

Horst Formlos

Schon die Prämisse ist falsch. Wieso glaubst du Webserver können nur eine derartig flache API (1) zum Weiterverarbeiten von Formular-Daten bereit stellen? Den Zusammenhang zwischen Formular-Kodierungen und Server-APIs habe ich ja bereits an anderer Stelle beleuchtet.

Das Szenario, das du beschreibst, sehe ich nicht als gegeben. Und noch schlimmer, verursacht du durch deinen Ansatz erst Probleme, wo vorher keine waren. Wieso benutzt du nicht das name-Attribut, um die Zusammengehörigkeit von Elementen zu kodieren? Wieso benutzt du da Klassen? Und wie würdest du tiefer verschachtelte Hierarchien mit Klassen kodieren? Webentwickler sind seit Jahren dazu in der Lage, diese Assoziationen im name-Attribut auf eine intuitive Art zu illustrieren. Es haben sich bestimmte syntaktische Konventionen herausgebildet, insbesondere die Notation über eckige Klammern:

Benannte Eigenschaften werden einfach so kodiert:

<input name="person[familienname]">  
<input name="person[rufname]">

Mit der selben Syntax, können wir auch tiefer verschachtelte Zusammenhänge ausdrücken:

<input name="person[adresse][plz]">  
<input name="person[adresse][stadt]">  
<input name="person[adresse][straße]">

Listen stellt man da, indem man ein Klammernpaar hinten anstellt.

<input name="geschwister[]">  
<input name="geschwister[]">

Diese Art der Notation ist inzwischen zu einem "de-facto"-Standard herangewachsen. Und das, weil sie einfach sehr gut funktioniert.

1. Du nennst das immer nur Stuktur, ich habe den Begriff mal etwas abstrakter gewählt. Die API kann beliebig komplex sein, es muss sich nicht um ein planes Parameter-Objekt handeln, wie etwa das $_POST-Array in PHP. Vergleiche das zum Beispiel mal mit der Komplexität von express' bodyParser.

[hotti]

hi,

Mit der selben Syntax, können wir auch tiefer verschachtelte Zusammenhänge ausdrücken:
[code lang=html]<input name="person[adresse][plz]">

Klar kannst Du das auch so ausdrücken. Indes: "person[adresse][plz]" ist und bleibt ein String, eine Sequenz. Egal ob GET oder POST übertragen wird stets:

key=value ; aneinandergereiht...

wobei das array auch nur dann erst beim Parser entsteht, wenn der entsprechend programmiert ist.

Weißt Du, für mich ist das nur Hobby, mir maln Kopp zu machen wie das auch anders und vielleicht sogar ein bischen besser gehen könnte. Letztendlich ist auch JSON genau derselbe Ansatz wie derjenige, den ich verfolge.

Und ich erzeuge auch nur Sequenzen, jedoch nicht mit textlichen Mitteln strukturiert, sondern auf Byte-Ebene, womit dann auch die Übertragung von Binärdaten möglich ist. Dabei beschränke ich mich nur auf das Entity-Attribute-Value-Pattern, meine Datenstrukturen sind da gar nicht weiter tief geschachtelt. Das müssen die auch gar nicht sein, denn mit EAV kannste schon ne ganze Menge machen wie z.B. dies oder das.

Interessant wird eine Low-Level-Serialisierung auch dann, wenns ans Wiederherstellen der Daten geht, auf meine Art und Weise lese ich die Daten serverseitig gleich aus STDIN. D.h., die Deserialisierung beginnt umittelbar mit der Ankunft der ersten Bytes, das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen). Des Weiteren benötigen Binärsequenzen weniger Bandbreite als vergleichbare Datenmengen die mit textlichen Mitteln strukturiert sind.

Den Enctype="application/json" finde ich interessant, besonders ab dem Zeitpunkt, wenn das die Browser unterstützen und damit auch Uploads möglich sind. Auf jeden Fall interessanter als multipart/form-data, das ist auf meiner Sicht reif fürs Museum (lass mich das doch ruhig so sagen, wäre ja noch schöner, wenn nicht).

Es ist nie zu spät über neue Techniken nachzudenken, sich darüber auszutauschen und auch mal was Neues auszuprobieren. In der Entwicklung gibt es keinen Stillstand. Insofern ist der Spruch "das Rad neu erfinden..." ziemlich dämlich und zeugt nur davon, dass derjenige, der den verwendet, überhaupt keine Ahnung hat worum es eigentlich geht.

Schönes Wochenende!

PS: Richtig Schwimmen kannste auch mit 60 lernen. Ich bin zwar erst 58, schwimme leidenschaftlich gerne und ausdauernd, kann mittlerweile auch längere Strecken richtig gut Kraulen, aber von Rudi und seiner Rentnerclique kann ich mir immernoch was abgucken ;)

[1UnitedPower]

Meine Herren!

Mit der selben Syntax, können wir auch tiefer verschachtelte Zusammenhänge ausdrücken:

<input name="person[adresse][plz]">

Klar kannst Du das auch so ausdrücken.

Und das hat einen entscheidenden Vorteil gegenüber deiner Idee: Man bleibt kompatibel zur Standard-Verhaltensweise von Formularen, die ganz gewöhnlich abgesendet werden. Es ist weder clientseitig noch serverseitig irgend eine Extra-Behandlung notwendig.

Indes: "person[adresse][plz]" ist und bleibt ein String, eine Sequenz. Egal ob GET oder POST übertragen wird stets:

key=value ; aneinandergereiht...

wobei das array auch nur dann erst beim Parser entsteht, wenn der entsprechend programmiert ist.

Jein. Ich glaube hier liegt ein Schlüssel vergraben, um das komplexe Zusammenspiel der Akteure zu verstehen. Deshalb möchte ich hier noch weiter ins Detail gehen:

person[adresse][plz] ist ein Identifikator. Mit ihm soll eine Eigenschaft assoziert werden. In dieser Form lässt er sich als Pfad auffassen. Das Konzept von Pfaden findet in der IT immer wieder Anwendung. Zum Beispiel bei Verzeichnispfaden: person/adresse/plz oder als Zugriffsmechanismus in JavaScript: person.adresse.plz. Das Konzept ist einfach zu begreifen.

Wenn wir irgendwo einen HTML-Quelltext lesen und dort steht [code lang=html]<input name="person[adresse][plz]" value="1234">

  
Das Prinzip ist aber nicht nur vom Menschen leicht zu verstehen, es ist auch auf Computern leicht zu implementieren. Wie eben gesehen ist das Prinzip sehr abstrakt, und das können wir uns selbst in diesem simplen Formular-Beispiel sehr zu Nutze machen. JSON kennt zum Beispiel auch das Konzept von hierarchischen Daten. Wir können den Pfad person[adresse][plz] auch als Pfad auf folgendere JSON-Struktur interpretieren:  
  
~~~javascript
{  
   "person" : {  
      "adresse" : {  
         "plz" : "1234"  
      }  
   }  
}

Und genau das wird (in Zukunft) auch gemacht, wenn wir ein Formular mit dem MIMEType application/json verschicken. Andererseits gibt es MIMETypes, insbsesondere application/x-www-form-urlencoded, die das Konzept von hierarchischen Daten nicht kennen. Das ist der Punkt, an dem du sagst: am Ende ist es nur eine perfide Sequenz von Schlüssel-Wert-Zuweisungen. Und wenn man sich den Request-Body einer solchen Anfrage anschaut, dann hast du sogar Recht. ABER das spielt keine Rolle, in anderem Kontext, nehmen wir diesmal PHP, kann es wieder das Konzept von hierarchischen Daten geben. Und das ist genau der Punkt, an dem eine PHP-Umgegung sich sagt "Moment mal, diese Formular-Daten, kann ich aber schöner aufbereiten". Und genau das macht PHP und es parst die Daten in das $_POST-Array. Und dort können wir wieder mit dem nun altbekannten Konzept des Pfades, die Eigenschaft einfach auslesen: $_POST['person']['adresse']['plz'].

Diese beiden Fälle sind offenbar sehr unterschiedlich, aber wir mussten an keiner Stelle eine Sonderbehandlung entwickeln. Hierarchische Daten und Pfade um einzelne Elemente darin zu identifizieren sind ein so abstraktes Konzept, dass es auf beide Fälle anwendbar war, die zunächst mal nur wenig Gemeinsamkeiten erkennen ließen.

Letztendlich ist auch JSON genau derselbe Ansatz wie derjenige, den ich verfolge.

Nein, du wählst einen spezialisierten Ansatz, der nicht verträglich mit bestehenden Konzepten und Denkweisen ist. Es muss ensteht für den Entwickler ein echter Mehraufwand, aber ohne dabei einen qualitativen Mehrwert zu Leisten.

Und ich erzeuge auch nur Sequenzen, jedoch nicht mit textlichen Mitteln strukturiert, sondern auf Byte-Ebene

Das ist eine weitere Spezialisierung, die du vornimmst und die hier keinen effektiven Mehrwert erzeugt. Mit dem Ansatz, den ich hier bewerbe, kannst du völlig agnostisch davon arbeiten, ob die Daten textlich oder binär weiterverarbeitet werden. Diese Verantwortlichkeit bleibt ganz alleine bei dem Kodierungs-Algorithmus liegen. Das nennt sich Seperation of Concerns.

Interessant wird eine Low-Level-Serialisierung

Du bist nicht Low-Level. Du argumentierst ja gerade für eine höhere Software-Schicht, ich argumentiere dagegen.

das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen).

Mit solchen Performanz-Aussagen musst du vorsichtig sein, hast du Benchmarks oder theoretische Erörterungen darüber, die dir das bescheinigen? Außerdem ist Performanz häufig ein Ziel, das im Widerspruch zu einer guten Software-Architektur steht. Deswegen ist es häufig so, dass man Leistungs-Optimierung nicht auf Verdacht betreibt, sondern indem man die Software auf Flaschenhälse analysiert und dann zielgerichtet optimiert, wo Bedarf besteht.

Des Weiteren benötigen Binärsequenzen weniger Bandbreite als vergleichbare Datenmengen die mit textlichen Mitteln strukturiert sind.

Wie gesagt, das ist kein exklusiver Vorteil von deinem Lösungsansatz. Das haben wir schon alles umsonst, wenn wir einfach so wenig wie möglich machen.

Es ist nie zu spät über neue Techniken nachzudenken, sich darüber auszutauschen und auch mal was Neues auszuprobieren.

Das sage ich auch nicht, ich demonstriere gerade glaube ich sehr genau das Gegenteil, indem ich mich hier mit dir austausche ;)

[hotti]

hi,

Nein, du wählst einen spezialisierten Ansatz, der nicht verträglich mit bestehenden Konzepten und Denkweisen ist. Es muss ensteht für den Entwickler ein echter Mehraufwand, aber ohne dabei einen qualitativen Mehrwert zu Leisten.

Nicht verträglich betrifft nur den Transport. Die Datenstrukturen bleiben dieselben, egal ob mein Serializer EAV.js oder JSON zum Einsatz kommt. D.h., der Transport-Layer ist austauschbar.

Und ich erzeuge auch nur Sequenzen, jedoch nicht mit textlichen Mitteln strukturiert, sondern auf Byte-Ebene

Das ist eine weitere Spezialisierung, die du vornimmst und die hier keinen effektiven Mehrwert erzeugt. Mit dem Ansatz, den ich hier bewerbe, kannst du völlig agnostisch davon arbeiten,

Das kann ich auch, schließlich ist ein Serializer auch nichts weiter als eine Möglichkeit zur Datenabstraktion, nämlich für den Transport zum Erzeugen von Sequenzen.

ob die Daten textlich oder binär weiterverarbeitet werden.

Eine mit textlichen Mitteln vorgenommene Serialisierung berührt den Layer Darstellung, im Fall JSON gar ist Code das Mittel für den Transport. Eine Low-Level-Serialisierung jedoch findet auf Byte-Ebene statt, dieser Layer hat weder mit Datentypen noch mit Zeichen noch mit Code oder anderen Inhalten zu tun.

Schließlich haben sich die Entwickler des OSI-Referenzmodells auch was dabei gedacht.

Hast Du Dir meine Beispiele mal angeguckt, wie einfach das letztendlich wird, Texte zusammen mit Binärdaten per HTTP zu übertragen? Wenn ich das mit herkömmlichen "Standards" machen müsste, wirds wesentlich komplizierter. Und genau das ist das Ziel meiner Entwicklungen.

Diese Verantwortlichkeit bleibt ganz alleine bei dem Kodierungs-Algorithmus liegen.

Ja klar, wo denn sonst ;)

Das nennt sich Seperation of Concerns.

Eine Doktorarbeit könnte ich auch schreiben. Ich bin aber eher der Praktiker.

Interessant wird eine Low-Level-Serialisierung

Du bist nicht Low-Level. Du argumentierst ja gerade für eine höhere Software-Schicht, ich argumentiere dagegen.

Nein eben nicht, siehe weiter oben. Ein herkömmlicher Parser nimmt den Parameter-String (oder die POST Daten) komplett in den Hauptspeicher um ihn in die Einzelteile zu zerlegen. Bei multipart/form-data wird, sofern die Komponente den file-Parameter drin hat, eine temp. Datei angelegt. Das kostet CPU, IO und RAM.

Ein Low-Level-Serializer hingegen verzichtet auf rechenintensive Stringoperationen, er erzeugt für Längenangaben Bytes (JS: ArrayBuffer, DataView) oder liest Bytes (PHP, Perl: pack, unpack). Die Bytes der Nutzdaten werden entweder aus einem Handle gelesen oder in ein Handle geschrieben. Während der Übertragung ist das Handle ein Socket, am Server angekommen, ist es STDIN. Von Perl oder PHP ausgehend ist es dann STDOUT in Richtung Webserver und dann wieder das Socket (bitte nicht verwechseln mit Websocket).

das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen).

Mit solchen Performanz-Aussagen musst du vorsichtig sein, hast du Benchmarks oder theoretische Erörterungen darüber, die dir das bescheinigen?

Ich stelle zunächst nur Überlegungen erster Ordnung an und freue mich darüber, dass moderne Browser mit Binärdaten umgehen können. Btw. alle Inhalte meiner Website (370 HTML-Seiten) liegen ebenfalls in einer Binärdatei. Hier gehts nicht um den Transport sondern um Persistenz, aber der Algorithmus ist derselbe um neue Seiten da einzutragen (das läuft bei mir über einen Webservice) oder Einzelseiten da wieder rauszuholen, was bei jedem Request passiert. Da stelle ich auch ohne Benchmark fest, dass die ganze Datei (ca 1MB) schneller ausgelesen, als eine DB-Connection hergestellt ist. Aber auch dieser Layer ist austauschbar, eine Zeile Code ;)

Und fürs performante Auslesen meiner Routingtable habe ich mir was ganz besonderes einfallen lassen: Die liegt als Binary direkt in einem Perlmodul und wird mit use eingebunden.

Außerdem ist Performanz häufig ein Ziel, das im Widerspruch zu einer guten Software-Architektur steht. Deswegen ist es häufig so, dass man Leistungs-Optimierung nicht auf Verdacht betreibt, sondern indem man die Software auf Flaschenhälse analysiert und dann zielgerichtet optimiert, wo Bedarf besteht.

Es ist immer eine Gratwanderung zwischen CPU, IO und RAM.

Des Weiteren benötigen Binärsequenzen weniger Bandbreite als vergleichbare Datenmengen die mit textlichen Mitteln strukturiert sind.

Wie gesagt, das ist kein exklusiver Vorteil von deinem Lösungsansatz. Das haben wir schon alles umsonst, wenn wir einfach so wenig wie möglich machen.

Vollkommen richtig, das sind wir uns einig. Siehe weiter oben und meine schönen Beispiele.

Es ist nie zu spät über neue Techniken nachzudenken, sich darüber auszutauschen und auch mal was Neues auszuprobieren.

Das sage ich auch nicht, ich demonstriere gerade glaube ich sehr genau das Gegenteil, indem ich mich hier mit dir austausche ;)

Dann gib Dich doch mal zu erkennen und ich hoffe das bleibt dabei ;)

Wie gesagt, alles nur Hobby. Hätte ich einen Job, fehlte mir dafür die Zeit. Andererseits bedeutet die Arbeit (Hobby) mit meinem Framework mittlerweile einen beträchtlichen Zeitgewinn, da sind neue Anwendungen ratz fatz entwickelt. Dieses FW ist letztendlich auch nur das Ergebnis meiner beruflichen Praxis und aus diesen Erfahrungen heraus behaupte ich, dass eine Firma, die mit diesem FW entwickeln würde, mit demselben Programmiererpotential mindestens dreimal soviel Aufträge annehmen könnte.

So habe ich mein FW auch mal in einer Firma eingesetzt um einen Fehler zu finden, den andere Programmierer nach Wochen nicht gefunden haben, obwohls ihn selbst da reinprogrammiert hatten. Mit meinem FW war das eine halbe Stunde Arbeit.

Schöne Grüße :)

PS: Respekt vorm Alter erwarte ich nicht, die 58 siehst Du mir ohnehin nicht an ;)

[1UnitedPower]

Meine Herren!

Nein, du wählst einen spezialisierten Ansatz, der nicht verträglich mit bestehenden Konzepten und Denkweisen ist. Es muss ensteht für den Entwickler ein echter Mehraufwand, aber ohne dabei einen qualitativen Mehrwert zu Leisten.

Nicht verträglich betrifft nur den Transport.

Nein, das betrifft sehr vieles. Das erste Problem ist, dass man aus dem puren HTML-Quelltext bei dir nicht mehr instinktiv sagen kann, welche Daten überhaupt verschickt werden. Ein Webseiten-Entwickler wird als erstes einen Blick auf die Namen und Werte der Formular-Felder werfen, er wird nicht davon ausgehen, dass auch Klassennamen an den Server geschickt werden. Das ist auch unnatürlich. Das wird von keiner bestehenden Formular-Kodierung gemacht. Das ist kognitiver Workload, den der Entwickler aufbringen muss, um sich deinen Ansatz hinein zu denken. Bei reglementierten Kodierungen, gibt es diesen nicht.

Und das ist ein schwerwiegendes Problem: Weil man das Standard-Verhalten einfach aushebelt, müssen Integrations-Tests vorgenommen werden. Und deine bisherige Implementierung würde da eiskalt durchfallen: Du hebelst nämlich die gesamte Formular-Validierung aus und erzeugst so eine riesige Barriere. Jetzt, da du das weißt, kannst du deine Implementation anpassen, aber der Punkt sollte deutlich werden: Standard-Verhalten zu deaktivieren ist eine gefährliche Sache.

Die nächste Inkompatibilität ist technischer Natur: Mit den nativen Möglichkeiten eines Browsers ist es nicht möglich ein Formular in deiner Kodierung zu versenden. Es muss clientseitig erst Code geschrieben werden, damit das ermöglicht wird.

Das selbe Spiel muss auch auf dem Server gespielt werden, auch dort muss Code geschrieben werden damit deine Kodierung erkannt wird. Und da ergibt sich sofort das nächste Problem: Der notwendige Dekodierungs-Algorithmus wird üblicherweise über den übermittelten MIMEType ausgehandelt, das ist nicht möglich, weil du keinen expressiven MIMEType überträgst. Es muss also eine Ausnahmebehandlung extra für deinen Kodierung übermittelt werden. Es gibt kein objektives Kriterium, an dem Mann überhaupt feststellen könnte, ob deine Dekodierung angewandt werden müssten. In einem kleinen Software-Projekt ist das okay, du weißt ja schließlich was ankommt, und wie damit zu verfahren ist. In größeren Software-Projekten ist das nicht tragbar.

Die Datenstrukturen bleiben dieselben, egal ob mein Serializer EAV.js oder JSON zum Einsatz kommt. D.h., der Transport-Layer ist austauschbar.

Was verstehst du unter dem Transport-Layer? Ich glaube nicht, dass du auf TCP hinaus möchtest. Ich weiß auch nicht, wie sich diese Aussage mit deinem ersten Satz "Nicht verträglich betrifft nur den Transport" vertägt.

Unabhängig davon, die Datenstrukturen werden schon vor der Übertragung durch die Kodierung verändert. In dem Beispiel aus meinem letzten Beitrag habe deutlich gemacht, dass application/json etwa das Konzept von hierarchischen Datenstrukturen kennt, application/x-www-form-urlencoded kennt dies nicht. Wie sollen diese beiden Kodierungen eine verträgliche Repräsentation finden?

Den Rest deiner Antwort, werde ich mir morgen vorknüpfen ;) Bin gerade leider abkommandiert worden, um ein Bier mit Freunden zu trinken.

[hotti]

hi,

Was verstehst du unter dem Transport-Layer?

Transport-Layer; damit meine ich nur die Verpackung. Ja, Du hast recht, ich hebele in /formlos.html die Standards aus. Das sehe ich aber nicht so dramatisch, solange das innerhalb einer in sich geschlossenen Anwendung passiert, wo z.B. Bilder erfasst werden und ein PDF rauskommt.

Es gibt schlimmere Sachen, die draußen passieren, da kann ich ein Lied davon singen, siehe mein Beispiel im letzten Post von vorhin, wo die Fehlerbehandlung sträflich auf der Strecke bleibt. Und oft genug habe ich verlorengegangene Warenkörbe rekonstruieren müssen bis hin über binlog-Auswertungen, weil grundsätzliche Dinge im Umgang mit persistenten DB-Verbindungen von Kollegen nicht verstanden wurden.

Das EAV-Model eignet sich übrigens auch zum Abbilden hierarchischer Strukturen, die Daten liegen in 3 Feldern (egal ob Datenbank oder Sequenz) und das braucht nur ein zusätzliches Attribut 'parent' für jede Entity (E ist hier der URL).

Über die Mengenlehre (nested sets) brauchts ein paar Felder mehr, ist aber auch nicht zwingend an eine DB gebunden, eine DB-Engine macht allerdings die Abfragen einfacher und auch performanter.

Last but not least kann auch das CSV-Format nach EAV transformiert werden, wie ich hier mal aufgeschrieben habe und hier verwende ich eine EAV/CSV als Speicherort für die komplette Perldoc was eine "alles-in-einer-html-datei-lösung" ist (Daten, Datenauswahl, Darstellung, die Daten liegen als CSV getarnt in einem <div>).

Den Rest deiner Antwort, werde ich mir morgen vorknüpfen ;) Bin gerade leider abkommandiert worden, um ein Bier mit Freunden zu trinken.

Viel Spaß dabei, ich bevorzuge Milchmixgetränke gegenüber Bier. Aber Zucker ist auch Gift :)

Schönes Wochenende ;)

[hotti]

Na, ausgeschlafen ;)

Und das ist ein schwerwiegendes Problem: Weil man das Standard-Verhalten einfach aushebelt, müssen Integrations-Tests vorgenommen werden. Und deine bisherige Implementierung würde da eiskalt durchfallen: Du hebelst nämlich die gesamte Formular-Validierung aus und erzeugst so eine riesige Barriere. Jetzt, da du das weißt, kannst du deine Implementation anpassen, aber der Punkt sollte deutlich werden: Standard-Verhalten zu deaktivieren ist eine gefährliche Sache.

Das Streben nach etwas mehr Struktur in der Übertragung von POST- oder GET-Parametern ist nicht neu. Ein <input name="address[name]"> ist auch nur eine proprietäre Lösung die PHP beschreitet, weil der serverseitige Parser im Builtin entsprechend programmiert ist.

Mit demselben Ziel auch proprietär, ermöglicht jedoch mit dem Standard Enctype="application/octet-stream" das Upload mehrerer Dateien beliebigen Content-Types zusammen mit Text unter konsequenter Nutzung der Möglichkeiten, die moderne Browser heute bieten.

Schönes Wochenende ;)

[1UnitedPower]

Meine Herren!

Das ist eine weitere Spezialisierung, die du vornimmst und die hier keinen effektiven Mehrwert erzeugt. Mit dem Ansatz, den ich hier bewerbe, kannst du völlig agnostisch davon arbeiten,

Das kann ich auch, schließlich ist ein Serializer auch nichts weiter als eine Möglichkeit zur Datenabstraktion, nämlich für den Transport zum Erzeugen von Sequenzen.

Das kannst du nicht, bei dir müssen Server- und Client-Software jeweils genaue Kenntnis voneinander haben. Das ist eine logische Folgerung daraus, dass du keinen expressiven MIMEType überträgst, der es Server oder Client ermöglichen könnte eine eigene Interpretation der Daten anzustellen.

ob die Daten textlich oder binär weiterverarbeitet werden.

Eine mit textlichen Mitteln vorgenommene Serialisierung berührt den Layer Darstellung, im Fall JSON gar ist Code das Mittel für den Transport.

Verschiedene Kodierungen für die selben Daten, haben immer eine andere Gestalt, eine andere Repräsentation. Diese Repräsentation, völlig unabhängig davon, ob sie binär oder textuell ist, ist immer Teil der Darstellungsschicht, im Sinne des OSI-Modells.

Eine Low-Level-Serialisierung jedoch findet auf Byte-Ebene statt, dieser Layer hat weder mit Datentypen noch mit Zeichen noch mit Code oder anderen Inhalten zu tun.

Low-Level und High-Level verläuft hier nicht zwischen textuell und binär. Du ignorierst das Potenzial von HTTP zum Übermitteln des MIMETypes. Der MIMEType ist aber wichtig, er teilt dem Kommunikationspartner mit wie die Daten zu verstehen sind, wie er sie interpretieren soll. Low-Level wäre es, davon Gebrauch zu machen. Du verschleppst diese Information aber, du vereinbarst sozusagen eine stillschweigende Übereinkunft von Client und Server, dass die Daten im Sinne deiner benutzerdefinierten Kodierung zu verstehen sind. Auf diese Art formalisierst du deine eigene HÖHERE Protokollschicht.

Schließlich haben sich die Entwickler des OSI-Referenzmodells auch was dabei gedacht.

Und du arbeitest genau gegen diese Trennung der Verantwortlichkeiten, die im OSI-Modell verankert werden. Wenn du das OSI-Modell schon anführst: Wieso nimmst die Aufgaben der Darstellungsschicht in die Verantwortung der Anwendungsschicht? Genau das machst du nämlich.

Hast Du Dir meine Beispiele mal angeguckt, wie einfach das letztendlich wird, Texte zusammen mit Binärdaten per HTTP zu übertragen? Wenn ich das mit herkömmlichen "Standards" machen müsste, wirds wesentlich komplizierter. Und genau das ist das Ziel meiner Entwicklungen.

Ich finde genau das Gegenteil ist der Fall. Du machst dir Arbeit, wo keine sein muss. Hier ist ein komplettes Beispiel, wie man das erreichen kann:

<form action="foo" enctype="multipart/form-data">  
   <input name="textdaten">  
   <input type="file" name="binärdaten">  
   <button>Abschicken</button>  
</form>

Wie geht es denn bitte noch einfacher?

Diese Verantwortlichkeit bleibt ganz alleine bei dem Kodierungs-Algorithmus liegen.

Ja klar, wo denn sonst ;)

Ich meinte damit die Kodierung, die man im HTTP-Header übermittelt. Du defninierst nur application/octet-stream und triffst dann Annahmen über die tatsächlich enthaltenen Daten.

Das nennt sich Seperation of Concerns.

Eine Doktorarbeit könnte ich auch schreiben. Ich bin aber eher der Praktiker.

Die Theorie findet ihre Anwendung in der Praxis und die Praxis motiviert die Theorie.

Interessant wird eine Low-Level-Serialisierung

Du bist nicht Low-Level. Du argumentierst ja gerade für eine höhere Software-Schicht, ich argumentiere dagegen.

Nein eben nicht, siehe weiter oben.

Eben doch, siehe weiter oben.

Ein herkömmlicher Parser nimmt den Parameter-String (oder die POST Daten) komplett in den Hauptspeicher um ihn in die Einzelteile zu zerlegen.

Mit Parser meinst du einen Dekodierer. Und dass alle Daten, die verarbeitet werden sollen in den Hauptspeicher geladen werden müssen steht außer Frage. Das wirst du auch nicht umgehen können.

Bei multipart/form-data wird, sofern die Komponente den file-Parameter drin hat, eine temp. Datei angelegt. Das kostet CPU, IO und RAM.

Das ist keine technische Notwendigkeit und auch kein spezifiziertes Verhalten. Du argumentierst gegen einzelne Implementationen. Aber der Flaschenhals einer Webanwendung liegt ohnehin nicht bei den Schreib/Lese-Vorgängen auf das lokale Dateisystem des Servers, sondern in Bandbreite der Netzwerk-Schnittstelle.

Ein Low-Level-Serializer hingegen verzichtet auf rechenintensive Stringoperationen, er erzeugt für Längenangaben Bytes (JS: ArrayBuffer, DataView) oder liest Bytes (PHP, Perl: pack, unpack).

Low-Level-Serialisierer ist falsch. Du meinst einfach nur eine Kodierung mit binärer Repräsentation der Daten.

Die Bytes der Nutzdaten werden entweder aus einem Handle gelesen oder in ein Handle geschrieben.

Das Konzept von einem handle gibt es auch bei Dateioperationen. Ich weiß nicht, worauf du hinaus möchtest.

Während der Übertragung ist das Handle ein Socket, am Server angekommen, ist es STDIN. Von Perl oder PHP ausgehend ist es dann STDOUT in Richtung Webserver und dann wieder das Socket

Und?

das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen).

Mit solchen Performanz-Aussagen musst du vorsichtig sein, hast du Benchmarks oder theoretische Erörterungen darüber, die dir das bescheinigen?

Ich stelle zunächst nur Überlegungen erster Ordnung an und freue mich darüber, dass moderne Browser mit Binärdaten umgehen können.

Konnten sie schon immer. Neu ist die JavaScript-API um mit binären Daten zu arbeiten und die nutzt du, um natives Verhalten nachzubauen. Wirklich interessant sind diese APIs bei clientseitigen Problemen, wie bei WebGL, wo performante Programmierung einen hohen Stellenwert erfordert.

Btw. alle Inhalte meiner Website (370 HTML-Seiten) liegen ebenfalls in einer Binärdatei.

Zu den Interna deines Frameworks kann ich nichts sagen, ist ja nicht offen.

PS: Respekt vorm Alter erwarte ich nicht, die 58 siehst Du mir ohnehin nicht an ;)

Jeder in diesem Forum, der an einer aufrichtigen Debatte interessiert ist, genießt meinen Respekt, unabhängig von Alter, Wissensstand und sonstigen Einflüssen, du zählst auf jeden Fall dazu ;)

[M.]

Mahlzeit,

Letztendlich ist auch JSON genau derselbe Ansatz wie derjenige, den ich verfolge.

Rad neu erfinden?

Das ein Class-Attribut einen bestimmten zweck hast, weisst du ja sicher. Dass du diese aber missbrauchst und damit für den eigentlichen Zweck praktisch unbrauchbar machst, weisst du noch nicht?
Es gibt doch für solche Dinge die Data-Attribute. Ich würde dein Konzept nicht nutzen. Denn entweder brauche ich class, dann kann ich es nicht nutzen oder ich brauche class nicht, dann werd ich meinen Quelltext nicht aufblähen, nur um etwas anders zu machen, was gar nicht nötig ist.

Und ich erzeuge auch nur Sequenzen, jedoch nicht mit textlichen Mitteln strukturiert, sondern auf Byte-Ebene, womit dann auch die Übertragung von Binärdaten möglich ist.

Und verhinderst damit absolut jede Funktion, wenn Javascript nicht ausgeführt wird.
Etwas von Javascript abhängig zu machen was mit purem HTML möglich ist und zusätzlich keinen Mehrwert bringt, ist mMn ein absoluter Fehlschuss.

[hotti]

moin,

Rad neu erfinden?

Du hast nicht verstanden worum es geht: Ich schlage nur eine andere Lösung vor, genauso proprietär wie PHP das handhabt: Mehr Strukturierung in Request-Parametern.

Das ein Class-Attribut einen bestimmten zweck hast, weisst du ja sicher. Dass du diese aber missbrauchst und damit für den eigentlichen Zweck praktisch unbrauchbar machst, weisst du noch nicht?

Das ist ein Trugschluss. Das class-Attribute wird nicht missbraucht sondern bekommt lediglich eine zusätzliche Aufgabe. Zur Gestaltung wird es ohnehin eingesetzt.

Es gibt doch für solche Dinge die Data-Attribute.

Von welchen Dingen redest Du hier?

Etwas von Javascript abhängig zu machen was mit purem HTML möglich ist und zusätzlich keinen Mehrwert bringt, ist mMn ein absoluter Fehlschuss.

JavaScript ist der Mehrwert. Browser die das unterstützen gibts kostenlos.

Viele Grüße ;)

[M.]

Mahlzeit,

Du hast nicht verstanden worum es geht: Ich schlage nur eine andere Lösung vor, genauso proprietär wie PHP das handhabt: Mehr Strukturierung in Request-Parametern.

Was du machst, ist eine Lösung, die es fix in mehreren Sprachen gibt mit einer Sprache nachzubauen, die diesen Sprachen die Struktur übermittelt, die sie direkt vom Browser auch bekommen.

Das ist so als wenn du bei einem Elektroauto per Akku einen Motor antreibst, der treibt einen Generator an, mit dessen Strom der Antriebsmotor gespeist wird.

Das ist ein Trugschluss. Das class-Attribute wird nicht missbraucht sondern bekommt lediglich eine zusätzliche Aufgabe. Zur Gestaltung wird es ohnehin eingesetzt.

Richtig, es wird zur Gestaltung eingesetzt. In einem Formular haben dann z.B. alle input-Elemente die gleiche Klasse, die zu einer deiner Datenstrukturen gehören, somit ist es nicht möglich, die Klasse zur Gestaltung und für die Datenstruktur gleichzeitig zu nutzen. Wenn jetzt das Aussen noch unterschiedlich sein soll, geht gar nichts mehr.
Und jetzt kommt noch, ich brauche seit langem keine Klassen mehr in Formularen, dafür gibt es passende Selektoren.

Zusätzlich bleibt, die missbrauchst das klar definierte class-Attribut für Zwecke, für die es nicht vorgesehen ist.

Es gibt doch für solche Dinge die Data-Attribute.

Von welchen Dingen redest Du hier?

Ich rede von dem Einsatz eigener Attribute, die keine vordefinierte Funktion haben. Das ist genau das, was du benutzen solltest, dafür gibt es die.

JavaScript ist der Mehrwert. Browser die das unterstützen gibts kostenlos.

Du weisst hoffentlich selbst, was das für ein Dummfug ist.

[hotti]

hi,

Es gibt doch für solche Dinge die Data-Attribute.

Von welchen Dingen redest Du hier?

Ich rede von dem Einsatz eigener Attribute, die keine vordefinierte Funktion haben. Das ist genau das, was du benutzen solltest, dafür gibt es die.

Mit dem data-Attribut gehts genau andersherum, da müsstest Du erst die Objekte über die id's ermitteln und dann die Gruppierung vornehmen.

Aber Du musst meinem Vorschlag nicht folgen, die Konkurrenz ist ja auch noch da :)

JavaScript ist der Mehrwert. Browser die das unterstützen gibts kostenlos.

Du weisst hoffentlich selbst, was das für ein Dummfug ist.

Dem Benutzer ist die Technik scheisegal, dem ist es vollkommen Wurscht ob eine Anwendung nur mit Javascript geht oder nicht.

Schöne Grüße!

[Gunnar Bittersmann]

@@hotti:

nuqneH

Dem Benutzer ist die Technik scheisegal,

Ja, solange sie das tut, was ihn an sein Ziel bringt.

dem ist es vollkommen Wurscht ob eine Anwendung nur mit Javascript geht oder nicht.

Einem Nutzer, der auf Tastaturbedienung oder assitive Technologien (wie bspw. Screenreader) angewiesen ist, ist es nicht Wurst, ob eine Anwendung nur mit Maus/Touch geht oder nicht.

Natürlich kann man das mit tabindex- und WAI-ARIA-Attributen nachrüsten. Nur ist das Dummfug, weil HTML schon Elemente bereithält, mit denen das bereits nativ funktioniert.

Qapla'

[M.]

Mahlzeit,

Mit dem data-Attribut gehts genau andersherum, da müsstest Du erst die Objekte über die id's ermitteln und dann die Gruppierung vornehmen.

Exakt so, wie es die Specs vorsehen.

Dem Benutzer ist die Technik scheisegal, dem ist es vollkommen Wurscht ob eine Anwendung nur mit Javascript geht oder nicht.

Das ist ein totaler Irrtum. Das wäre nur der Fall, wenn es genauso funktionieren würde. Das tut es aber nicht.

Das wäre so als wenn eine Werkstatt die Bremsen bei nem Auto ausbaut, nen Anker installiert und dann zum Kunden sagt "Ist doch egal mit welcher Technik die Bremse funktioniert".

Du kommst mir vor, als wenn du mit Gewalt irgendwas erfinden willst und dann glaubst du, alle anderen müssten deine Begeisterung teilen weil es ja so innovativ ist.

Eine Innovation ist nicht das nachbauen einer Funktion (in deinem Fall mit komplizierten Hintergrund, womit du einfaches nachbaust). Innovation ist u.a. das Vereinfachen von Standards um sie mehr Menschen nahezubringen. Du gehts genau den umgekehrten Weg. Du machst etwas einfaches kompliziert und schränkst gleichzeitig den Benutzerkreis ein.

[Gunnar Bittersmann]

@@M.:

nuqneH

Rad neu erfinden?

Zitat hotti und was ich davon halte

Qapla'

[M.]

Mahlzeit,

Zitat hotti

In diesem Fall praktisch JSON nachzubauen, da geh ich davon aus, diese Rad ist schon erfunden und lächt reichlich rund ;)

und was ich davon halte

ACK

[Gunnar Bittersmann]

@@M.:

nuqneH

Rad neu erfinden?

Man kann übrigens nicht nur Formular(element)e, sondern auch Hyperlinks neu erfinden. ROTFL.

Qapla'

PS: Der Artikel ist genauso gemeint, wie er geschrieben ist.

[Martin R.]

Rad neu erfinden?
Man kann übrigens nicht nur Formular(element)e, sondern auch Hyperlinks neu erfinden.

Wie gewohnt kam die Pointe erst ganz am Schluss: “Please enable JavaScript to view the comments powered by Disqus.”

\0

[Gunnar Bittersmann]

@@Martin R.:

nuqneH

Wie gewohnt kam die Pointe erst ganz am Schluss: “Please enable JavaScript to view the comments powered by Disqus.”

Wo ist dort die Pointe?

JavaSript-Ausschaltern (wer macht sowas?) sollte klar sein, dass ihnen nicht alles zur Verfügung steht. Dem Nutzer wird gesagt, welchen Mehrwert JavaSript auf der Seite bietet. Seine Entscheidung, ob er diesen nutzen will.

Qapla'

[Texter mit x]

Dem Nutzer wird gesagt, welchen Mehrwert JavaSript auf der Seite bietet. Seine Entscheidung, ob er diesen nutzen will.

Er kann gleich die ganze Seite mit JS anzeigen, dann hat das noch mehr von dem was Du hier Mehrwert nennst.

[M.]

Mahlzeit,

Man kann übrigens nicht nur Formular(element)e, sondern auch Hyperlinks neu erfinden. ROTFL.

Verdammt, da hab ich immer a-Elemente benutzt und dabei ginge es mit nem div genauso. Da kann ich eine komplette nur aus divs bauen und brauch nicht vier vielen anderen, völlig unötigen Elemente.

Kann man durch div auch noch body, title, head usw. ersetzen? Würde ne Menge an Lernarbeit einsparen *g*

[MrMurphy]

Hallo,

ich bevorzuge schlichte anwenderfreundliche Formulare. Der Besucher soll sie möglichst einfach bedienen und lesen können. Deshalb wähle ich auch eine große Schrift.

Weiterhin sollten Checkboxen und Radiobuttons auch durch Klicken auf den zugehörigen Text aktiviert bzw. deaktiviert werden können.

Eine Bedienung nur mit der Tastatur sollte möglich sein.

Zudem steht bei mir der Text durchgängig einheitlich immer vor den Eingabe- bzw. Auswahlfeldern.

u.s.w.

Kurz: Bei mir steht der Besucher im Vordergrund.

Und ich erstelle meine Seiten zukunftsorientiert, nutze also aktuelles HTML und CSS.

Ein Beispiel:

http://foreninfo.bplaced.net/seiten_flexbox/flexbox_12_formular_01.html

Gruss

MrMurphy

[hotti]

hi,

Ein Beispiel:

http://foreninfo.bplaced.net/seiten_flexbox/flexbox_12_formular_01.html

Das sieht sehr gut aus, <label> genutzt, benutzerfreundlich und responsive. Danke dass Du mir ein so schönes Beispiel hier verlinkst!

Viele Grüße, schönes Wochenende,
 Horst Formlos

[Gunnar Bittersmann]

@@hotti:

nuqneH

http://foreninfo.bplaced.net/seiten_flexbox/flexbox_12_formular_01.html

Das sieht sehr gut aus,

Find ich nicht. Die Eingabefelder sind mir zu breit.

benutzerfreundlich

Nein. Im Firefox erkennt man nicht, welches Eingabefeld den Fokus hat.

Qapla'

[MrMurphy]

Hallo,

Nein. Im Firefox erkennt man nicht, welches Eingabefeld den Fokus hat.

Das habe ich mal in deinem Sinne angepasst. Für checkbox und radio habe ich leider keine Möglichkeit der Hervorhebung bei :focus gefunden. Wenn du eine Möglichkeit kennst wäre es schön, wenn du die hier mitteilen würdest.

Find ich nicht. Die Eingabefelder sind mir zu breit.

Ich habe die Felder extra so breit gemacht, damit die Besucher möglichst immer den gesamten Text sehen, den sie eingeben. Wenn du sie schmaler haben möchtest gibst du ihnen halt ein margin mit auf den Weg. Meine Erfahrung ist halt, das Besucher, die ihren eingegebenen Text noch mal zur Kontrolle nachlesen, nicht noch mal in Eingabefelder klicken und scrollen wollen.

Gruss

MrMurphy

[Klaus]

Das sieht sehr gut aus,

Find ich nicht. Die Eingabefelder sind mir zu breit.

Das sieht genau so aus, als hätte ein Programmierer es gemacht.

Fürchterlich.

Sorry, Mr. Murphy, aber da ist wirklich nullkommanull Design drin.

Klaus

[MrMurphy]

Hallo,

danke für deine Einschätzung.

Ich habe das Formular nach den Wünschen des TE erstellt, also

Schön heißt: Benutzerfreundlich, responsive, funktional.

Ein richtiges Design kann ich erst erstellen, wenn ich den Rest der Seite kenne. Darum ging es dem TE aber offensichtlich nicht, sonst hätte er dazu Angaben gemacht.

Was würdest du denn mit den vorhandenen Informationen designmäßig verbessern? Oder hast du einen Link zu einem besseren Beispiel?

Gruss

MrMurphy

[Klaus]

Hallo,

danke für deine Einschätzung.

Ich habe das Formular nach den Wünschen des TE erstellt, also

Schön heißt: Benutzerfreundlich, responsive, funktional.

Ok. Das ist eine neue Definition von "schön".
Aber dem TO gefällt es ja auch, also alles richtig gemacht. 2 Nicht-Designer unterhalten sich über "schöne" Formulare und raus kam das, was sich Nichtdesigner (Programmierer) darunter vorstellen. Ich fand das ziemlich typisch. (was nicht heißt, daß Du nicht wirklich "schöne" Formulare erstellen kannst (denn das kann ich nicht beurteilen).

Was würdest du denn mit den vorhandenen Informationen designmäßig verbessern? Oder hast du einen Link zu einem besseren Beispiel?

Ich finde einige Forularideen hier und hier ganz gut.

Klaus

[Kay]

Liebe Leute,

ungezählte Webanwendungen habe ich programmiert die erstklassig funktionieren, aber besonders schön sind die nicht, weil: Ich bin (noch) nicht so der Designer. Deswegen möchte ich mir ein paar ganz besonders schöne Formulare mal anschauen, Ihr habt da bestimmt was zum herzeigen.

Schön heißt: Benutzerfreundlich, responsive, funktional.

Willst du einen Designpreis gewinnen?

Bei Anwendungen im gewerblichen Bereich ist auf Conversationsrate zu optimieren.
Was nutz einem ein ästhetisch geiles Teil, wenn man 20 bis 80 Prozent weniger Eintragungen hat?
Für ein Hobbyprojekt mag das ja egal sein. Aber für Projekte wo Gewinne erwirtschaftet werden müssen, zählt mMn nur die Benutzerfreundlichkeit und die Eintragunsrate.

[hotti]

hai Kay,

Willst du einen Designpreis gewinnen?

Nein, ich bin nicht der Wettkämpfertyp ;)

Für ein Hobbyprojekt mag das ja egal sein. Aber für Projekte wo Gewinne erwirtschaftet werden müssen, zählt mMn nur die Benutzerfreundlichkeit und die Eintragunsrate.

Das ist doch mal ein richtig guter Hinweis, danke!

Naja, mit dem Herzeigen, das lassen wir mal gut sein für heute ;)

Schönes Wochenende!

[Gunnar Bittersmann]

@@Kay:

nuqneH

Aber für Projekte wo Gewinne erwirtschaftet werden müssen, zählt mMn nur die Benutzerfreundlichkeit und die Eintragunsrate.

Zum einen kann sich das widerspechen. Usability: Gib dem Nutzer die Möglichkeit abzubrechen. (Steuerbarkeit in ISO 9241-110). Conversion: Gib dem Nutzer keine Möglichkeit abzubrechen.

Als Kompromiss wird man einen Abbrechen-Button vorsehen, diesen aber nicht so prominent gestalten wie den Call-to-Action-Button. Der Nutzer soll nicht dazu gebracht werden zu überlegen, ob er denn auch wirklich wirklich kaufen möchte.

Allerdings ist auch hohe Conversion nicht unbedingt das erstrebenswerte Ziel. Man hat wenig davon, wenn Nutzer viel bestellen, aber es sich später anders überlegen und das meiste davon zurücksenden.

Zum zweiten sind Kaufentscheidungen oft auch emotional. Das Design eines Fomulars hat Einfluss auf Kaufentscheidungen. Das betrifft Interaktionsdesign (Reihenfolge, wann welche Daten erhoben werden), Grafikdesign und auch Tonalität der Texte (wie der Nutzer angesprochen wird).

Qapla'

[Kay]

Conversion: Gib dem Nutzer keine Möglichkeit abzubrechen.

Glaub ich nicht, der User kann auch den Browser schließen.

Allerdings ist auch hohe Conversion nicht unbedingt das erstrebenswerte Ziel. Man hat wenig davon, wenn Nutzer viel bestellen, aber es sich später anders überlegen und das meiste davon zurücksenden.

Das sehe ich in der Praxis zum Teil ganz anders. Es mag bei einen Warenkorb mit physischen Artikeln teilweise gelten. Aber es gibt auch genügent Produkte die nicht zurück geschickt werden können. Oder man kann Formulare für Sachen verwenden, wo es nicht um einen Verkauf geht. Mir sind sogar Fälle bekannt, wo eine Verdopplung der Conversationrate, die durchschnittliche Stornorate verringert hat (War aber auch nicht Mode oder Schuhe).

Bei einer hohen Retourenrate, liegt das Problem wahrscheinlich an mehreren Problemzonen in der Prozesskette des Verkaufs, aber nicht in einer zu hohen Conversationsrate.

Zum zweiten sind Kaufentscheidungen oft auch emotional. Das Design eines Fomulars hat Einfluss auf Kaufentscheidungen. Das betrifft Interaktionsdesign (Reihenfolge, wann welche Daten erhoben werden), Grafikdesign und auch Tonalität der Texte (wie der Nutzer angesprochen wird).

Das Design hat Einfluss auf die Interaktion, ja. Wir hatten doch neulich im Forum einen Beitrag wo ein neu gestalteter Shop ca. 30 % Umsatzeinbruch brachte, weil die Designer alles richtig machten. Agentur und Geschäftleitung waren happy, nur der Kunde spielt nicht mit.

Die Praxis zeigt mir aber auch, das schlechtes oder gar kein Design oft erheblich mehr zum wirtschaftlichen Erfolg beiträgt, als sogenanntes gutes Design. Ich würde hier auch eher vom "verkaufsoptimierten Design" sprechen oder noch lieber von einem conversions optimierten Prozess. Hier muss man aber auch das ganze Umfeld betrachten. Welche Zielgruppe, kalter oder warmer Traffic, befindet der User sich in einen Verkaufsfunnel, Farbpsychologie, Schriftästhetik, Verkaufspsychologie, NLP, wird Text, Video oder/und Audio eingesetzt. Es gibt sicher noch mehrere Dutzend andere Faktoren die Einfluss haben können.

[Gunnar Bittersmann]

@@Kay:

nuqneH

Bei einer hohen Retourenrate, liegt das Problem wahrscheinlich an mehreren Problemzonen in der Prozesskette des Verkaufs, aber nicht in einer zu hohen Conversationsrate.

Sicher nicht nur an einer zu hohen Conversationsrate, und nicht hauptsächlich daran. Aber vielleicht doch ein kleines Bisschen.

Ich wollte nur auf die Gefahr aufmerksam machen, dass wenn man den Nutzer durch den Kaufprozess peitscht, er sich’s später, wenn er Zeit hat, doch wieder anders überlegt und dem Betreiber mir Retouren Kosten verursacht.

Wir hatten doch neulich im Forum einen Beitrag wo ein neu gestalteter Shop ca. 30 % Umsatzeinbruch brachte, weil die Designer alles richtig machten.

Alles richtig gemacht – außer: nicht an den Nutzer gedacht. Jedenfalls nicht an den Großteil: die Bestandskunden. Für Neukunden war die neue Website bestimmt besser, nur die Bestandskunden erkannten ihren gewohnte Shop nicht wieder.

Deshalt: Redesign will wohl überlegt sein. Wenn es keine zwingenden Gründe für eine komplette Neugestaltung gibt: Änderungen in kleinen Schritten.

Oder wie man hier so schön sagt: Wir müssen die Leute da abholen, wo sie sind.

Die Praxis zeigt mir aber auch, das schlechtes oder gar kein Design oft erheblich mehr zum wirtschaftlichen Erfolg beiträgt, als sogenanntes gutes Design.

Es gibt nicht gar kein Design. Es gibt wohl auch kein schlechtes Design, nur unpassendes.

Und ja, auf einer hochwertig gestylten Website wird man keine Schnäppchen erwarten. Wenn man solche verkaufen will, wäre ein solche Website unpassend und wenig vertrauenserweckend. Andersrum ebenso: billig aussehende 08/15-Website für hochwertige Produkte.

Hier muss man aber auch das ganze Umfeld betrachten.

Das kann nie falsch sein. ;-)

Qapla'

[mrjerk]

Hallo,
Ich habe das gleiche Problem wie Du (bin auch eher "Techniker" als Grafiker, und das ganze Web ist mir oft viel zu bunt :)), und nutze in Fällen, wo ich nicht auf meine geschätzen Grafik-Kollegen zurück greifen kann, CSS-Frameworks wie Bootstrap oder Ink.

Wirkliche Designpreise wirst Du damit nicht gewinnen (insbesondere, weil eine Bootstrap-Seite, sofern man nicht selber eigene Ideen einarbeitet, halt aussieht wie 2Mio. andere Bootstrap-Seiten ;)), es kommt aber (sofern richtig eingesetzt) i.d.Regel was raus, was "okay" aussieht und benutzbar ist.

Evtl. ist es auch nur als Anregung für die eigenen Formular-Elemente hilfreich.

Viele Grüße,
Jörg

[Gunnar Bittersmann]

@@mrjerk:

nuqneH

Wirkliche Designpreise wirst Du damit nicht gewinnen (insbesondere, weil eine Bootstrap-Seite, sofern man nicht selber eigene Ideen einarbeitet, halt aussieht wie 2Mio. andere Bootstrap-Seiten ;))

Und wenn die Seite nicht so aussehen soll wie 2Mio. andere Bootstrap-Seiten, dann lässt man von Bootstrap am besten gleich die Finger.

und nutze in Fällen, wo ich nicht auf meine geschätzen Grafik-Kollegen zurück greifen kann, CSS-Frameworks wie Bootstrap oder Ink.

Bootstrap ist für Falle, wo man nicht auf geschätzte Frontent-Kollegen zurückgreifen kann.

es kommt aber (sofern richtig eingesetzt) i.d.Regel was raus, was "okay" aussieht und benutzbar ist.

Ist „okay“ okay?

Qapla'