Feedback Statische Seiten (2.x-Beta)

[yellowled]

Neuer Thread aus Übersichsgründen. Diskussion hier und auf deutsch, da tendenziell hoher Diskussionsbedarf. Primär Feedback für Ian, aber offen zur Diskussion. Getestet mit 4.21 aus Ians Repository im 2.0-Backend.

Die meisten der optischen Anmerkungen kann ich übernehmen ([YL]) und sie Ian als PR schicken, die funktionalen nicht unbedingt.

Allgemein

* Es fehlt eine Bereichsüberschrift (h2) im Inhaltsbereich. [YL]
* Der Rahmen der Subnavigation sollte auch links und rechts sein (Konsistenz). [YL]
* Die Hervorhebung des aktiven Items der Subnavigation sieht „irgendwie merkwürdig“ aus. Zudem funktioniert sie erst nach dem ersten Bereichswechsel.
* Fieldsets haben eigenes CSS (Konsistenz). [YL]
* Das Plugin verwendet z.T. alte Versionen der Iconfont-Icons (Konsistenz). [YL]
* Ein paar Dinge (Hide/Show TabBar, Form Pagetype) sollten noch lokalisiert werden.
* Sollte in der Seitenreihenfolge besser der Titel (zusätzlich) und/oder die ID ausgegeben werden?
* Die Andere-Plugin-Tabelle ist inkonsistent gestaltet und verwendet unnötige eigene msg-Klassen (Konsistenz). [YL]

Seiten bearbeiten:

* Die Pagination sollte so funktionieren wie z.B. unter „Einträge bearbeiten“ – optisch und funktional. Sie sollte nicht anders aussehen und nicht nur über JS realisiert sein. Sie sollte nur ausgegeben werden, wenn Sie auch „nötig ist“ und die gleichen „Umbruchgrenzen“ haben.
* Der Kontrast für den lang-Indikator ist bedenklich niedrig. [YL]
* Feature request: Ich fände zwei actions für Seiten nützlich (falls machbar) – Seite duplizieren und Unterseite unterhalb anlegen.
* Man könnte 404-Seiten mit einem Label markieren. Wird eigentlich geprüft, ob nur genau eine 404-Seite definiert ist?
* Man kann auf Seiten anhand ihrer ID zugreifen (unten), die ID wird aber in der Seitenliste nicht ausgegeben.
* Ich ahne, dass das kompliziert ist, aber sollten Unterseiten hier nicht unterhalb ihrer Elternseiten gelistet werden?
* Die Ausgabe der Metadaten im Frontend funktioniert nicht, für description und keywords wird nur ein > ausgegeben (siehe http://nbe.netzgestaltung.net/pages/lorem-ipsum.html)

Seiteneditor

* Das Responsive Template ist ein guter Ansatz, aber es passt auf ganz kleinen Screens nicht. [YL]
* Warum überhaupt ein separates Responsive Template, im 2.x-Backend sollte alle responsive sein? Abwärtskompatibilität für 1.x? Dann sollte das Responsive Template in 2.x Default sein.
* Kleinigkeit: Diese „-Oder-“-Trenner haben wir überall entfernt, sie sind unnötig. [YL]
* Die Labels der Show/Hide-Bereiche brauchen kein „Zeige“, die Großschreibung ist inkonsistent zum restlichen Backend. [YL]
* Der Bereich „Struktur-Optionen“ lässt sich nicht dauerhaft einklappen (alle anderen schon).

[yellowled]

Nachtrag, weil's mir gerade so auffiel:

Wir müssten uns in dem Zusammenhang auch mal einfallen lassen, wie wir es lösen, dass 1.x und 2.x ggf. separates CSS vom Plugin erhalten. Die meisten dieser als „inkonsistent im 2.x-Backend“ eingestuften Styles funktionieren vermutlich im 1.x-Backend bzw. sind dort sogar notwendig, im 2.x-Backend würde man sie aber komplett anders gestalten.

Das brauche ich z.B. auch für die meisten der anderen additional_plugins, die ich bereits für 2.x angepasst habe.

YL

[Timbalu]

* Der Rahmen der Subnavigation sollte auch links und rechts sein (Konsistenz). [YL]

Gibt es, nur etwas weniger stark; border-color: #BBB #DEDEDE; (Fand ich persönlich besser so)

* Die Hervorhebung des aktiven Items der Subnavigation sieht „irgendwie merkwürdig“ aus. Zudem funktioniert sie erst nach dem ersten Bereichswechsel.

Das liegt am default fallback und war schon immer so - nur das die tabs nicht als tabs erkennbar waren, sondern nur als aktive links. Kann man ändern, wenn man will, muss man aber nicht, denn so wie jetzt, sind tabs nur dann aktiv, wenn man sie auch wirklich benutzt hat.

* Das Plugin verwendet z.T. alte Versionen der Iconfont-Icons (Konsistenz). [YL]

Jein. Es emuliert sie (und die msg_classes) nur ein wenig anders, da 1.7 keinen iconfont mitbringt, und ich für staticpages nicht extra eines benutzen wollte.

* Sollte in der Seitenreihenfolge besser der Titel (zusätzlich) und/oder die ID ausgegeben werden?

Ich habe (bisher) auf den Titel oder ID verzichtet, da es wichtig war eine möglichst kurze aber erkennbare Anzeige zum Verschieben zu haben. Da bot sich der unique url-titel förmlich an.

* Die Pagination sollte so funktionieren wie z.B. unter „Einträge bearbeiten“ – optisch und funktional. Sie sollte nicht anders aussehen und nicht nur über JS realisiert sein. Sie sollte nur ausgegeben werden, wenn Sie auch „nötig ist“ und die gleichen „Umbruchgrenzen“ haben.

Ich möchte nicht alles wiederholen, was ich dazu schon geschrieben habe. (Bitte lesen)
Entries und staticpages sind in der Pagination nicht vergleichbar, da staticpage pagination nur (js-)fake im userland ist. Ich zweifle immer noch ob sich eine echte Pagination mit all seinen extra requests wirklich lohnt.

* Feature request: Ich fände zwei actions für Seiten nützlich (falls machbar) – Seite duplizieren und Unterseite unterhalb anlegen.
* Man könnte 404-Seiten mit einem Label markieren. Wird eigentlich geprüft, ob nur genau eine 404-Seite definiert ist?
* Man kann auf Seiten anhand ihrer ID zugreifen (unten), die ID wird aber in der Seitenliste nicht ausgegeben.
* Ich ahne, dass das kompliziert ist, aber sollten Unterseiten hier nicht unterhalb ihrer Elternseiten gelistet werden?

Das sind IMHO alles feature requests. Kurz: 404 weiß ich gerade nicht. ID Anzeige, hm - muss das wirklich? Echte Unterseiten ist eher kompliziert - lohnt das? (Auch dazu hatte ich schon geschrieben.)

* Die Ausgabe der Metadaten im Frontend funktioniert nicht

Das habe ich gestern auch schon gemerkt und heute schon gefixt. Danke.

* Das Responsive Template ist ein guter Ansatz, aber es passt auf ganz kleinen Screens nicht. [YL]

Für das Finetuning hatte ich schwer mit dir gerechnet!

* Warum überhaupt ein separates Responsive Template, im 2.x-Backend sollte alle responsive sein? Abwärtskompatibilität für 1.x? Dann sollte das Responsive Template in 2.x Default sein.

Das liegt daran, dass ich damit gerechnet hatte, dass mancher doch gerne das alte default template im Desktop weiter verwenden wollte. Für diejenigen, die Wert auf eine andere Anordnung, Klappmenus, etc, und auch auf Mobile View legen, habe ich das Responsive oder Mobile Template geschrieben.
Hat man sich einmal entschieden, bleibt die Einstellung ja erhalten.

* Die Labels der Show/Hide-Bereiche brauchen kein „Zeige“, die Großschreibung ist inkonsistent zum restlichen Backend. [YL]

Stimmt grundsätzlich. Aber mit dem gewohntem 1.7 Design sieht das schon wieder anders aus. Da müsste man nochmal überlegen, wer den Vorrang bekommt.

* Der Bereich „Struktur-Optionen“ lässt sich nicht dauerhaft einklappen (alle anderen schon).

Das kann ich weder lokal, noch im DEV Blog (mit FF && Chrome) bestätigen.

[yellowled]

Gibt es, nur etwas weniger stark; border-color: #BBB #DEDEDE; (Fand ich persönlich besser so)

Anekdote: Ich hatte sowas in der Art in 2k11/Frontend. Einer der ersten Benutzerreaktionen darauf war, man habe das Gefühl „als würde man links und rechts rausfallen“. Diese ganze Subnavigation ist schwierig, weil es dafür kein Muster im restlichen Backend gibt, aber da sonst überall Rahmen gleich sind …

Kann man ändern, wenn man will, muss man aber nicht, denn so wie jetzt, sind tabs nur dann aktiv, wenn man sie auch wirklich benutzt hat.

Ich würde das aktive Tab überhaupt nicht hervorheben wollen. Man sieht ja am Inhalt, wo man ist.

Es emuliert sie (und die msg_classes) nur ein wenig anders, da 1.7 keinen iconfont mitbringt, und ich für staticpages nicht extra eines benutzen wollte.

Ja, wie ich schrieb – den Fallback auf 1.x hatte ich weitestgehend nicht bedacht, sorry. Das ist eine gute Lösung so, aber im 2.x-Backend sollte es natürlich die „richtigen“ Icons usw. nutzen. Das müssen wir (siehe Post oben) nochmal im devTalk gucken, wie wir das schlau lösen.

Ich habe (bisher) auf den Titel oder ID verzichtet, da es wichtig war eine möglichst kurze aber erkennbare Anzeige zum Verschieben zu haben. Da bot sich der unique url-titel förmlich an.

Klar. Das Problem ist ja auch, dass vermutlich gar nicht wenige Benutzer ihren statischen Seiten ellenlange Titel mitgeben, man nicht wirklich ahnen kann, wie lang die werden, dann muss man wieder truncaten … bäh, das ist alles unschön. Hm. Mal sehen.

Ich möchte nicht alles wiederholen, was ich dazu schon geschrieben habe. (Bitte lesen)

Ich geb mir Mühe, das in den nächsten Tagen nachzulesen. Bitte ein bisschen Geduld haben. Sorry, dass ich es nicht schon mitgelesen habe, aber mein Kopf war in letzter Zeit zu voll mit anderen Bereichen des Backends, da habe ich das einfach ausgeblendet.

ID Anzeige, hm - muss das wirklich? Echte Unterseiten ist eher kompliziert - lohnt das? (Auch dazu hatte ich schon geschrieben.)

Ich ahnte es. Es ist halt irgendwie merkwürdig, wenn man es aus anderen Systemen so kennt. Andererseits reden wir hier von einem Plugin, was letztlich (auch wenn viele Benutzer das anders sehen) für ein paar wenige statische Seiten in einem Blog gedacht ist … was das „lohnt das?“ angeht – ich gehe davon aus, dass das viele Benutzer verwirren und feature requests dafür geben wird. Meinetwegen müsste es jetzt nicht sein, aber ich kann nicht einschätzen, wie viel nerviger es wäre, das ggf. später anzuflanschen.

Was die ID angeht – weiter unten gibt es ein „Schnellzugriff-Widget“, in das man genau diese ID eingeben soll. Ich weiß nicht, wie man das benutzen sollte, wenn die ID nirgends angeben wird. Nicht, dass ich an diesem Widget übermäßig hänge – ich könnte gut damit leben, das rauszunehmen.

Das liegt daran, dass ich damit gerechnet hatte, dass mancher doch gerne das alte default template im Desktop weiter verwenden wollte. Für diejenigen, die Wert auf eine andere Anordnung, Klappmenus, etc, und auch auf Mobile View legen, habe ich das Responsive oder Mobile Template geschrieben.

Das Problem ist aber doch, dass das Desktop Template in diversen Bildschirmgrößen des responsiven Backends nicht benutzbar ist. Es ist grundsätzlich total gut, dass es diese zwei Varianten gibt, wir brauchen ja eine als Fallback für 1.x, für das es wohl nie ein reponsives Backend geben wird. Aber für 2.x finde ich das irgendwie unsinnig, und selbst wenn es für bestimmte Benutzer sinnvoll wäre – das default in 2.x sollte responsive sein, nicht Desktop.

Aber mit dem gewohntem 1.7 Design sieht das schon wieder anders aus. Da müsste man nochmal überlegen, wer den Vorrang bekommt.

Hatte ich nicht bedacht, es sollte aber kein Problem sein, 1.x und 2.x unterschiedliche Beschriftungen zu servieren.

Das kann ich weder lokal, noch im DEV Blog (mit FF && Chrome) bestätigen.

Könnte ein FU mit dem aktuellen Stand sein, evtl. hängt es damit zusammen, dass da stellenweise das JS einen 404 lieferte oder so. Muss ich mir noch einmal ansehen.

YL

[Timbalu]

Anekdote: Ich hatte sowas in der Art in 2k11/Frontend. Einer der ersten Benutzerreaktionen darauf war, man habe das Gefühl „als würde man links und rechts rausfallen“. Diese ganze Subnavigation ist schwierig, weil es dafür kein Muster im restlichen Backend gibt, aber da sonst überall Rahmen gleich sind …

Ja den kenne ich.. Das war ich selbsts. Dennoch fand ich #bbb für left und right eher zu hart.

Ich würde das aktive Tab überhaupt nicht hervorheben wollen. Man sieht ja am Inhalt, wo man ist.

Eigentlich nur wenn man sehr genau hinschaut. Die hervorgehobenen Tabs helfen, finde ich schon seit längerem... aber vielleicht kann man das noch verschönern...?!

Was die ID angeht – weiter unten gibt es ein „Schnellzugriff-Widget“, in das man genau diese ID eingeben soll. Ich weiß nicht, wie man das benutzen sollte, wenn die ID nirgends angeben wird. Nicht, dass ich an diesem Widget übermäßig hänge – ich könnte gut damit leben, das rauszunehmen.

Wenn die ID bereits in der entrylist sichtbar wäre, benötigte man das Widget ja gar nicht, denn dann nimmt man den entry oder button link direkt. Es geht wohl vielmehr darum, mal eben schnell eine bestimmte ID die man im Kopf hat zu requesten.

das default in 2.x sollte responsive sein, nicht Desktop

Das ließe sich bestimmt machen, wenn wir da alle übereinstimmen.

Hatte ich nicht bedacht, es sollte aber kein Problem sein, 1.x und 2.x unterschiedliche Beschriftungen zu servieren.

Nun ja extra dafür doppelte CONSTANTS einzupflegen... hmmm

Ich werde nachher die letzten commits mal als 4.22 taggen, damit du auf darauf zugreifen kannst, oder gehts das auch so?

[Timbalu]

Wird eigentlich geprüft, ob nur genau eine 404-Seite definiert ist?

Soweit ich das sehe, nein!.
Wozu wäre das eventuell gut, bzw potentiell fehleranfällig wenn es mehrere gibt?

[yellowled]

Die hervorgehobenen Tabs helfen, finde ich schon seit längerem... aber vielleicht kann man das noch verschönern...?!

Bestimmt. Ich hab darüber noch nicht viel gebrütet.

Wenn die ID bereits in der entrylist sichtbar wäre, benötigte man das Widget ja gar nicht, denn dann nimmt man den entry oder button link direkt. Es geht wohl vielmehr darum, mal eben schnell eine bestimmte ID die man im Kopf hat zu requesten.

Klar, aber auch die weiß man ja nicht, wenn sie nirgends ausgegeben wird. Ganz ehrlich, ich halte dieses zusätzliche Widget mit der neuen Übersicht für unnötig. Jeder wird entweder das select oder die action-Buttons nehmen, um Seiten zu bearbeiten.

Ich werde nachher die letzten commits mal als 4.22 taggen, damit du auf darauf zugreifen kannst, oder gehts das auch so?

Öhm. Ich hab beim letzten Mal einfach den master aus Deinem extra Repository genommen. Das könnte ich dann wieder tun. Den extra zu taggen wäre bestenfalls für mich minimal bequemer. Meinetwegen nicht nötig.

Wozu wäre das eventuell gut, bzw potentiell fehleranfällig wenn es mehrere gibt?

Weiß ich nicht, zumal es auf netzgestaltung ohnehin nicht funktioniert. (Was eventuell daran liegen könnte, dass dort eine 404-Seite per .htaccess gesetzt wird bzw. von der .htaccess der übergeordneten Domain.)

Ich gehe halt davon aus, dass es immer nur genau eine 404-Seite geben darf. Keine Ahnung, was passiert, wenn da mehrere definiert sind – vermutlich wird nur die zuletzt definierte verwendet? (Reine Spekulation.)

YL

[Timbalu]

Ganz ehrlich, ich halte dieses zusätzliche Widget mit der neuen Übersicht für unnötig.

Wie ich Garvin kenne, behält er soetwas gerne... es war bestimmt einmal irgendein feature request.

extra zu taggen ... Meinetwegen nicht nötig.

Umso besser. Dann kann das noch warten. Wenn du dir das nochmal rüberziehst, haben wir jedenfall im DEV Blog den aktuellen Status.

Ich gehe halt davon aus, dass es immer nur genau eine 404-Seite geben darf. Keine Ahnung, was passiert, wenn da mehrere definiert sind – vermutlich wird nur die zuletzt definierte verwendet? (Reine Spekulation.)

Ja, das nehme ich auch an. Jedenfalls sehe ich nirgendwo einen Fehler, wenn es zwei gibt.
Wie genau das gemeint war/ist, kann sicherlich auch Garvin beantworten.

[yellowled]

Wie ich Garvin kenne, behält er soetwas gerne... es war bestimmt einmal irgendein feature request.

Dabei gibt es aber auch Dinge, die sinnvoll und weniger sinnvoll sind. Und wenn die ID, die man in das Widget eingeben soll, nirgends ausgegeben wird, ist das Widget für 90% der Benutzer sinnlos.

Wenn du dir das nochmal rüberziehst, haben wir jedenfall im DEV Blog den aktuellen Status.

Erledigt. Ich weiß noch nicht, ob ich schon Änderungen machen möchte, eventuell ist es besser, wir sprechen das im devTalk (siehe nebenan) nochmal durch. Mal sehen.

Jedenfalls sehe ich nirgendwo einen Fehler, wenn es zwei gibt. Wie genau das gemeint war/ist, kann sicherlich auch Garvin beantworten.

Ich weiß nicht, wie 404-Seiten genau umgesetzt werden – falls sie nur in die .htaccess eingetragen werden (glaube ich aber nicht), dürfte die zuletzt eingetragene bei mehreren entscheidend sein. In der .htaccess auf netzgestaltung steht derzeit nur

Code: Select all

ErrorDocument 404 /index.php

Das dürfte auch erklären, wieso die statische 404-Seite, die ich angelegt habe, nicht funktioniert.

YL