Wording "Anzeigeformat"

[marcohanke]

Hier bin ich auch schon öfter drüber gestolpert. Anzeigeformat klingt für mich nach der konkreten Anzeige, also auch im Backend. Es meint aber nur die Listendarstellung. Vielleicht gibt es hier was "besseres" oder noch eine Info dazu in der Art: Anzeigeformat (In Listendarstellung) oder ähnliches

[dergel]

Gilt nicht nur für die Listendarstellunh, auch z.B. für Viewansichten im Backend von Tabellen.

Gerne einen besseren Namen - freue mich über Ideen

[marcohanke]

Viewansichten im Backend von Tabellen kenn ich nicht ;-) In der Doku schreibst du "Tabellen-Übersicht" wäre das okay? Falls ja würde ich auch hier #1179 In "Tabellen-Übersicht anzeigen" schreiben

[dergel]

Ich finde Darstellung besser.

[marcohanke]

Einfach nur "Darstellung" Da könnte ich jetzt genauso viel mit anfangen wie mit "Anzeigeformat" glaub ich

[dergel]

Ausgabeformat

[marcohanke]

Nachdem wir jetzt drüber Diskutiert haben werde ich es eh nicht mehr vergessen ;-) Trotzdem fände ich einen Bezug zur Tabelle bzw. Liste gut. Bei allem anderen gehe ich davon aus, dass die Ausgabe in der Tabelle im Backend und im Frontend gemeint ist.

[ynamite]

Ich fände es toll, wenn auch das Eingabe-Select/-Input das gewählte Ausgabe-/Darstellungs-/Anzeige-Format respektieren würde.

[alxndr-w]

Das Thema kam auf Slack neulich wieder auf, beim besten Willen kann ich nicht verstehen, wie man beim Ausgabeformat auf ein Eingabeformat kommt. Beim Datumsfeld im technischen Sinne muss das Datum standardisiert eingegeben werden.

Für eine optimale Eingabe für den Nutzer gibt es eigene HTML5-Input-Typen (date, time, datetime-local siehe #1230).

Imho: Wer was anderes benötigt und auf gültige Datumsangaben pfeifen kann, kann ein Textfeld benutzen.

[ynamite]

@alxndr-w naja, wenn bei der Felddefinitiion "Anzeigeformat" steht, ist das Wording aus reiner UX Sicht irreführend; ich (und offenbar auch viele andere) hätten erwartet, dass damit die Anzeige des Datums sowohl bei der Ein- und Ausgabe im BE gemeint ist.

Dass das Datum standardisiert in der DB landen soll, ist völlig klar. Ich persönlich habe erwartet, dass das Feld das eingegebene Datum, egal welches Anzeigeformat eingestellt ist, beim Speichern für die DB umformatiert und bei der Ausgabe (überall), gemäss eingestelltem Format darstellt.

Natürlich muss das nicht so sein, aber dann ist das Wording unglücklich. Zudem stellt sich dann bei mir die Frage, weshalb man überhaupt ein Format einstellen kann. Dann lieber ganz weglassen und man macht die Formatierung halt jeweils selber. Fände ich zwar schade aber immerhin konsequent.

[alxndr-w]

Was mir in der ganzen Diskussion dazu immer wieder auffällt: Jegliche Hinweise auf die Verwendung passender HTML-Eingabefelder - mit denen sich das Problem von selbst erübrigt - werden in der Diskussion konsequent ignoriert. Als gäbe es <input type="date" value="2022-04-12"> bspw. gar nicht.

Damit wird sowohl der Usecase gelöst, die Datumseingabe zu formatieren (bzw. die "Darstellung"/"Anzeige" der Datumseingabe), als auch die Frage geklärt, wofür das Anzeigeformat dann noch gut ist/wäre, nämlich:

1. In der Listenansicht, wo es auch Sinn ergibt, das am Feld einstellen zu können
2. In der Ausgabe im Frontend, wenn man den Wert darstellen will und dabei auf die hinterlegte Konfiguration zurückgreift.

Dazu muss man sich auch Zeit nehmen, zu verstehen, warum die eigenen Erwartungen hier nicht erfüllt werden und nicht die "schnell schnell irgendwas passt nicht ich lade das bei Slack und als Issue ab, sollen sich andere darum kümmern"-Mentalität fahren.

Und dann wird auch klar, dass es weder ein Issue, noch ein Bug, ist. Sondern ein Feature, das man nicht verstanden hat (auch ich zu anfangs).

[ynamite]

So kann man's natürlich auch sehen haha. Heute ev. mit dem falschen Fuss aufgestanden? ;) Wer sagt denn, dass deine Inputs betreffend HTML5-Input Types ignoriert werden? :)

Es geht darum, dass es offenbar von Vielen trotzdem falsch verstanden wird (gerade eben im Slack wieder), also ist das Wording imo suboptimal gewählt. Das ist schon alles. Hab ja geschrieben, dass es nicht so sein müsse (wie ich es gerne hätte).

Zudem kann mans durchaus anders sehen: selbst wenn man es über HTML5 Input Types regeln kann, könnte das Feld das ganze Prozedere für User vereinfachen, die vielleicht keine Ahnung von HTML haben – wie es viele andere Felder in yform auch tun (imageset, be_relation, be_table, custom_link, etc.). Ich dachte der Table-Manager sei dazu da, den Umgang mit Tabellen und Tabellen-Felder zu vereinfachen.

als auch die Frage geklärt, wofür das Anzeigeformat dann noch gut ist/wäre, nämlich:

Ich finde den Usecase jetzt relativ klein, wenn's nur das ist. Von mir aus kann das dann ganz raus 🤷 muss ja eh viele Felder für die Listenansicht manuell "verbessern".

Dazu muss man sich auch Zeit nehmen, zu verstehen, warum die eigenen Erwartungen hier nicht erfüllt werden und nicht die "schnell schnell irgendwas passt nicht ich lade das bei Slack und als Issue ab, sollen sich andere darum kümmern"-Mentalität fahren.

Ja gut, wenn das deine Ansicht dazu ist, dann könnte man sich imo gleich die Zeit nehmen Tabellen, Relationen, Feld-Typen, MySQL usw. beizubringen und ganz auf den Table-Manager verzichten. Nochmal, offenbar wird das Feld oft missverstanden, das ist doch die Krux am Issue.

Und dann wird auch klar, dass es weder ein Issue, noch ein Bug, ist. Sondern ein Feature, das man nicht verstanden hat (auch ich zu anfangs).

Sehe ich anders. Aber du, jeder wie er will.

[alxndr-w]

@ynamite da dürfen wir ja gerne unterschiedliche Ansichten haben und uns auch von unterschiedlichen Punkten einem Problem annähern. Womit ich auf jeden Fall mitgehe, ist, dass das Datums-Feld ohne eigene Anpassungen aktuell nicht brauchbar ist.

Heute ev. mit dem falschen Fuss aufgestanden? ;) Sehe ich anders. Aber du, jeder wie er will.

Mir gehen diese "Befindlichkeiten" manchmal auf den Keks. Das gleich ins Persönliche zu ziehen und Best Practice oder Standards zur "Meinung" zu erklären. Vor allem diskutiere ich hier nicht, um "Meinungen" auszutauschen, sondern Lösungen zu finden. Und da nervt es echt, wenn jeder nur bis zu seinem Tellerrand blickt, statt sich darauf einzulassen, dass es vielleicht einen anderen Lösungsweg gibt, der Vorteile hat gegenüber dem, wie man es bisher gemacht hat oder man etwas Neues dazu lernt. Ist das so verkehrt?

[alxndr-w]

Vorschlag: @ynamite @dpf-dd @marcohanke ihr schreibt hier mal die Szenarien runter, wo ihr das Datumsfeld aktuell einsetzt und was davon "nicht funktioniert" (zumindest nicht so wie gedacht / gewünscht) und dann schauen wir, wie man jedes einzelne Phänomen löst - mit Bordmitteln, mit Anpassungen oder PRs und Bugfixes.

[eaCe]

Ich will mich hier nicht einmischen, aber es ging um ein Wording, nicht um ein Problem mit dem Feld?

[ynamite]

@alxndr-w

Mir gehen diese "Befindlichkeiten" manchmal auf den Keks.

Du bist also doch auch nur ein Mensch, puh! ;) Im Ernst, ich verstehe dich schon, geht mir ja manchmal ähnlich.

Das gleich ins Persönliche zu ziehen und Best Practice oder Standards zur "Meinung" zu erklären.

Das haben aber hier weder Marco, Stefan noch ich getan oder? Hab jetzt nicht nochmal alles durchgelesen, aber kann mich nicht erinnern, persönlich geworden zu sein? Oder doch?

Vor allem diskutiere ich hier nicht, um "Meinungen" auszutauschen, sondern Lösungen zu finden.

Finde ich jetzt etwas sehr reduktiv, diese Aussage. Lösungsfindung ensteht auch durch Meinungsaustausch. Wenn du der Auffassung bist, dass nur deine Meinung zum Thema korrekt ist, ist das nicht sehr lösungsorientiert.

Und da nervt es echt, wenn jeder nur bis zu seinem Tellerrand blickt, statt sich darauf einzulassen, dass es vielleicht einen anderen Lösungsweg gibt, der Vorteile hat gegenüber dem, wie man es bisher gemacht hat oder man etwas Neues dazu lernt. Ist das so verkehrt?

Verkehrt nicht, im Gegenteil. Aber einfach ums geschrieben zu haben: was du da schreibst, kann man im Umkehrschluss auch genauso auf deine eigene (diese) Aussage anwenden. Meiner Meinung nach siehst du es aktuell etwas zu starr aus deiner persönlichen (vermutlich genervten) Perspektive ...

Womit ich auf jeden Fall mitgehe, ist, dass das Datums-Feld ohne eigene Anpassungen aktuell nicht brauchbar ist.

Eigentlich ist damit die Diskussion ja auch hin, betreffend HTML5 Input Types. Wären zwar ein Lösungsansatz, aber funktioniert ja eben doch nicht.

Wie @eaCe schreibt und ich vorhin schon mehrfach angedeutet habe, es geht in meinen Augen hauptsächlich ums missverstandene Wording. Völlig abgesehen von anderen Problemen dieses Feldtyps.

Szenarien: ich nutze das Datumsfeld praktisch ausschliesslich für, ehm, Datumsfelder; also ein Feld wo ein Redakteur ein Datum eintragen kann, z.B. für einen Blog-Eintrag oder so. Weil ich schlechte Erfahrungen mit Kalender-Widgets gemacht habe, die Bedienung teilweise umständlich ist (und's damit öfter andere Probleme gibt) und input:text ohne Widget praktisch unbrauchbar/fehleranfällig ist, rendere ich das Feld meist als Select. Wenn dann ein Redakteur aus dem deutschprachigem Raum das Select bedienen muss und's nicht im hier üblichen Format daher kommt (DD.MM.YYYY), dann find ich das halt etwas schade/doof, unabhängig davon, wozu die Einstellung Anzeigeformat gedacht ist.

[alxndr-w]

Also geht's darum, dass ihr mit dem Anzeigeformat die Reihenfolge bei den select-Feldern ändern möchtet? Und das aktuell das Format ignoriert und [YYYY🔻]-[MM🔻]-[DD🔻] daraus macht?

[ynamite]

Kann nur für mich selbst sprechen, aber ja. Zumindest dachte ich, dass die Einstellung dafür da ist. Marco's Issue war lediglich, wie er oben schreibt, dass das Wording unglücklich ist:

Hier bin ich auch schon öfter drüber gestolpert. Anzeigeformat klingt für mich nach der konkreten Anzeige, also auch im Backend. Es meint aber nur die Listendarstellung. Vielleicht gibt es hier was "besseres" oder noch eine Info dazu in der Art: Anzeigeformat (In Listendarstellung) oder ähnliches

[alxndr-w]

Also wenns das ist, dann kam das für mich aus keiner der Diskussionen rüber. Manchmal wären zwei Screenshots soll/ist da hilfreich, um zu verstehen, worum es geht.

Für mich persönlich fällt das Rendern als select mit so Eingabemöglichkeiten wie 31. Februar komplett unten durch. Keine optimierte Tastatur am Tablet/mobil, keine Ansicht nach Wochentagen.

Die Beschränkung auf bestimmte Zeiträume (z.B. Kalenderjahre) könnte man auch mit einem date-Input imho viel besser lösen, weil da wirklich ein min/max datumsgenau geht. Das dynamisch einzustellen fehlt aber glaube ich aktuell im YForm, wenns nicht als select gerendert wird.

@ynamite

Weil ich schlechte Erfahrungen mit Kalender-Widgets gemacht habe

Die würden mich echt interessieren, wenn du noch Zeit hast.

[ynamite]

@alxndr-w komisch ist, dass es sonst alle kapiert haben ... Maybe it's you? ;)

Die würden mich echt interessieren, wenn du noch Zeit hast.

Gerne. Mit Widgets hatten ich (und einige andere User) ganz ähnliche Probleme, wie Stefan aktuell in Slack. Inkosistenten bei Ein- und Ausgaben bzw. der Anzeige im Widget. Hab irgendwann aufgehört zu zählen, wie oft die Widgets bzw. Bootstrap Datetime-Picker statt einem Datum einfach NaN angezeigt hatten. Widgets kamen z.B. nicht damit klar, dass entweder kein Initialwert vorhanden war oder der Initialwert 0000-00-00 war und haben dann irgendein Datum weit in der Vergangheit gesetzt, was nicht gerade benutzerfreundlich ist. Oder wenn man ein Datums-Feld nur optional befüllen wollte, dies über Widgets nicht möglich war. Oder das sich Widgets mit input type="date" nicht vertragen haben, aus Gründen. Je nach eingestelltem Anzeigeformat, kam es in älteren yform Versionen ebenfalls zu Problemen, wenn ein bestehender Datensatz bearbeitet wurde (irgendeine Inkonsistenz Datumsformat zwischen neuen/bestehenden Datensätzen). Oder, dass das aktuelle locale nicht beachtet wurde. Hab in älteren yform Versionen selbst PRs zum JavaScript Datetime-Picker beigesteuret. Ganz zu schweigen von Inkonsistenzen zwischen den diversen Browsern. Wir reden hier von den letzten 10-15 Jahren.

Bestimmt noch Weiteres, ist aber alles schon ein Weilchen her. Jan und Thomas (Blum) können dir davon bestimmt auch ein Liedchen singen. Ich bilde mir das beileibe nicht alles ein ;) Wenn du im Redaxo Forum guckst, die Issues hier oder in Slack duchsuchst, wirst du sicherlich zum Thema fündig werden.

Mir hatte Thomas (Skerbis, glaube ich) vor einer gefühlten Ewigkeit empfohlen, auf Widgets zu verzichten und ich muss sagen: I've never looked back since. Bin so bis Dato recht gut gefahren und die Kunden kamen damit auch klar, trotz des "falschen" Anzeigeformats.

Anyway, alter Hut und zurück zum eigentlichen Thema: Wording :) Bist du nicht auch der Meinung, dass man das Wording optimieren könnte? Daneben, dass das Feld, wie du selbst schreibst, nicht richtig funktioiniert, wäre für mich damit das Thema gegessen.

[alxndr-w]

Da sieht man aber, von was wir alles unterschiedlich ausgehen, wenn man das so aufdröselt (worüber ich froh bin).

Ich rede jedenfalls nicht von diesen externen Skripten wie bspw. dem Bootstrap-Date-Picker, die dann als Widgets die Eingabe ermöglichen. Ich spreche wirklich von den browsereigenen Oberflächen, die in ihrer aktuellen Fassung bspw. auch zulassen, dass man das Datum überschreibt. Und da spreche ich auch nicht von den letzten 15 Jahren, sondern von den letzten 2 Jahren. (Was davor war, interessiert mich jetzt nicht mehr - kann aber nur unterschreiben, dass ich nie eine dieser verschlimmbesserten Zusatz-Widgets irgendwo eingebaut habe. Was ich schon an Hotelbuchungen verzweifelt bin ;))

Das (browsereigene) Widget kann jedenfalls nichts dafür, dass die initiale Eingabe nicht funktioniert, wenn man ihm das Datum nicht standardkonform (imho "falsch") übergibt. Deswegen auch mein PR.

Wegen des Wordings: Mein Ansatz ist halt um die Ecke gedacht, und deswegen war und bin ich da so beharrlich: Das Problem taucht nicht auf, wenn man's anders löst.

Deine Argumente in Bezug auf die Usability möchte ich respektieren, aber gleichzeitig die Augen dafür öffnen, dass es andere Lösungen gibt. Mit ebenfalls sehr guter Usability - vielleicht sogar besserer!

i18n: Datetime-Picker im Browser können sich nach der Browsersprache / Betriebssystemsprache richten. Warum soll ein Redakteur ein deutsches Format präsentiert bekommen, wenn er gar nicht eine deutsche Eingabe gewöhnt ist?

Konsistenz: Innerhalb des Ökosystems sehen alle Browser-Picker gleich aus. Es ist schlichtweg nicht relevant, ob ein Kalender-Widget zwischen Android, iOS, Windows Edge oder Firefox, Chrome, etc. gleich aussieht. Es ist nur wichtig, dass der Nutzer dasselbe präsentiert bekommt.

Deswegen kann ich da genauso sagen: I've never looked back since.

Aber, wenn du wirklich eine Antwort zum Wording haben willst: Mir fällt nichts besseres ein, außer die Darstellung zu fixen mit den select-Feldern, denn da würde ich erwarten, dass das mit inbegriffen ist und man darauf Einfluss nehmen kann - abgesehen davon, dass ich die selects nie nutzen würde. ;) Für mich ist das kein Wording-Problem, seitdem mir klar ist, worauf @ynamite du dich beziehst.

[alxndr-w]

komisch ist, dass es sonst alle kapiert haben ... Maybe it's you? ;)

Ich habe mich über das Issue mit jemandem unterhalten, der die Diskussion auch nicht verstanden hat und sehr viel mit REDAXO macht, von daher. Schau doch nochmal nach, wann hier der Begriff "select" fiel ;)

[ynamite]

@alxndr-w Ich mach's jetzt kurz und danach enthalte ich mich der weiteren Diskussion, weil so wichtig ist's mir dann auch wieder nicht. Du schreibst ganz viel und ganz fest am Thema vorbei.

Wenn du lieber immer wieder dieselben Fragen beantworten möchtest, betreffend dem Wording Anzeigeformat, obwohl du dich scheinbar über die Fragerei/Diskussion aufregst, dann sei's drum. Ich weiss ja mittlerweile, dass es irreführend beschrieben ist und wie ich damit umzugehen habe. Mir fallen übrigens mindestens 3 Varianten ein, die besser verständlich wären (Hinweis unter dem Feld, dass das Format ausschliesslich auf die Listendarstellung eine Auswirkung hat, z.B. oder man nennt es einfach Listendarstellungs oder Listendarstellungsformat, whatever)

Da sieht man aber, von was wir alles unterschiedlich ausgehen, wenn man das so aufdröselt (worüber ich froh bin). seitdem mir klar ist, worauf @ynamite du dich beziehst.

Du bist allerdings der, der von Unterschiedlichem ausgeht ;) respektive dir ist's noch immer nicht klar. Ich kenne die div. Input Types und Möglichkeiten betreffend locales usw., danke trotzdem. Deine Frage war, wieso ich mich damals von Widgets abgewendet hatte. Diese Gründe habe ich dir beschrieben. Der Grund wieso ich auch heute noch auf Selects setze, falls du neugierig bist, ist hauptsächlich, weil ich damit 10x schneller bin ein Datum einzustellen, als über ein Widget (egal ob Browser- oder JS-Widget).

Das (browsereigene) Widget kann jedenfalls nichts dafür, dass die initiale Eingabe nicht funktioniert, wenn man ihm das Datum nicht standardkonform (imho "falsch") übergibt. Deswegen auch mein PR.

Wo habe ich denn behauptet, dass das Browser-Widget etwas dafür kann?

Wegen des Wordings: Mein Ansatz ist halt um die Ecke gedacht, und deswegen war und bin ich da so beharrlich: Das Problem taucht nicht auf, wenn man's anders löst.

Das ist ja schön und gut, zumindest in der Theorie. In der Praxis nützt dir das leider nicht viel. Fakt ist ja, dass immer wieder User drüber stolpern und dieselbe Frage stellen. Aber hey, du darfst denen dann gerne jedesmal wieder daselbe erklären ;) Hast ja Übung.

Warum soll ein Redakteur ein deutsches Format präsentiert bekommen, wenn er gar nicht eine deutsche Eingabe gewöhnt ist? ... Konsistenz ... etc.

Äh, auch wenn ich dir bei vielem beipflichten würde, was hat das mit dieser Diskussion zu tun? Alle haben gecheckt das es ums Wording geht, welches User immer wieder verwirrt. Würde mich schon noch interessieren, wer auf diesen Thread hier bezogen, nicht nachgekommen ist ausser dir?

[ynamite]

Schau doch nochmal nach, wann hier der Begriff "select" fiel ;)

Ich fände es toll, wenn auch das Eingabe-Select/-Input das gewählte Ausgabe-/Darstellungs-/Anzeige-Format respektieren würde.

I don't see your point 🤷 hab doch nur beigefügt, dass ich es "toll fände".

[marcohanke]

Ich will jetzt nicht groß in die Diskussion einsteigen nur noch mal klar stellen: Das Issue hier ist einfach entstanden, weil ich, sowie andere Leute im Slack immer mal hier rüber stolpern und etwas anderes Erwarten als es tatsächlich ist. Es geht also nicht um den "richtigen" Weg für Usecase XY, sondern darum dass Dinge Missverstanden werden. Und wenn mehrere Leute etwas Missverstehen, finde ich schon dass man sich Gedanken machen kann, ob es vielleicht eine bessere Beschreibung hierzu gibt.