brainstorming: dashboard template UI mit jquery + x

[yellowled]

Das ist es jetzt schon, komplett möchte ich sagen.

Ich schreib ja nicht alles immer nur für Dich. (Wobei die Frage wäre, wer das ggf. noch nachliest …)

Das Ganze hat, wie Malte zurecht sagte, das Zeug für ein "nie-endendes Mammutprojekt", mit vielen divergierenden Meinungen. Für was plädierst du in dieser Sache?

Rein auf die Navi bezogen? select. Hat sich (siehe 2k11 auf kleinen Bildschirmen) für Navigationen absolut bewährt, wenn nur wenig Platz zur Verfügung steht.

Generell für das Dashboard? Erstmal als Plugin, das sich in die Admin-Oberfläche integriert. Keinesfalls so „vorgeschaltet“, weil das ungewohnt ist und 99% der Nutzer zunächst verwirren wird. Es hat Malte und mich verwirrt – stell Dir vor, was das mit Anfängern und Gelegenheitsnutzern macht …

YL

[yellowled]

Wenn eine valide Position ist, möglichst keine Farben zu setzen, sind die gesetzten Farben anzusprechen. Schon alleine der graue Hintergrund sorgt dafür, dass es aus dem Adminbereich heraussticht.

Es ist ja irgendwo ein Teufelskreis:

* Es gibt wenige Admin-Templates, weil es derzeit eine absolute Pest ist, das Backend zu gestalten.
* Es ist dermaßen nervig, das Backend zu gestalten, dass man nur das Nötigste macht und nicht zig Plugins testet, zumal kein Mensch im Kopf hat, welche Plugins definitiv etwas zum Backend hinzufügen, also versucht man eine allgemeingültige Gestaltung mit nicht sehr spezifischen Styleanweisungen und hofft, dass die halbwegs greifen.
* Plugin-Entwicker merken, dass diese allgemeinen Styles nicht greifen und bauen deshalb eigene ein.
* Die sind aber nur mit argen Verrenkungen zu überschreiben, weshalb kein Mensch Admin-Templates baut, womit die Katze sich in den Schwanz beißt.

Wie gesagt: Operation „Sauberes Backend“ läuft, aber halt zäh. Ich mag da im Moment meine Mitstreiter noch nicht drängeln, aber das alleine wird ohnehin nicht reichen – es nützt nichts, wenn der Kern ein sauberes Backend-Gerüst liefert und die Plugins dann aus der Reihe tanzen. Deswegen würde ich Stand jetzt darauf plädieren, die Backend-Komponenten einzelner Plugins wenig bis gar nicht zu gestalten, auch wenn das mitunter komisch aussieht und vermutlich nicht komplett verhindert, dass diese später an das überarbeitete Backend nochmals angepasst werden muss. Dann sollte aber zumindest das Backend-Template die Gestaltung komplett übernehmen.

YL

[Timbalu]

Ja. Was soll ihr Sinn sein? Ihr einziger Vorteil ist, dass die Navigation verschwindet, ...

Ich fand sie drängt nicht so, durch ihre Weite. Außerdem bot sie die Möglichkeit Boilerplate style.css und Modernizer mit allen Möglichkeiten und anderen Erweiterungen in den Backend Header zu integrieren. Sie schuf Platz für die Hilfe, war mal etwas anderes, gegenüber der jahrealten Ansicht, wurde zu einem Spielplatz, ohne etwas zu zerstören, nutzte mal die Dinge, die das Serendipity Admin Backend vorsieht, wie die noSidebar, noBanner und neu, die noFooter option, war allgemein Wert mal ausprobiert zu werden, schuf die Möglichkeit das Dashboard neu denken zu können, usw.
Dieser Bruch wäre dann ja auch nur ein Zwischenspiel...
Und alles darum, weil ich - in der embedded Ansicht - eher gelangweilt war und mich fragte was da eine Smartifizierung überhaupt bringen könne. (siehe Anfang des Threads)

Ich konnte nichts bewegen. ... Platzieren per Drag & Drop.

In der Config ist das vorgesehen, aber hatte bisher (meiner Erinnerung nach) keine Auswirkungen, da nirgends darauf Bezug genommen wurde. Jetzt schon! In der Dashboard Ansicht selbst hätte es die Blöcke nur noch mehr verkompliziert und noch mehr für Verwirrung gesorgt.

[Timbalu]

Ich schreib ja nicht alles immer nur für Dich.

Das ist aber mitunter schwer auseinanderzuhalten und nötigt manchmal auf etwas zu antworten, was eventuell nichts mit dem Kern der Fragestellung zu tun hat.

Zur Backend Gestaltung? Ich weiß was du meinst, zB .serendipityAdminContent span mit diesen sehr netten !important rules, die sich immer wieder hartnäckig einer Besänftigung entziehen wollen.

- es nützt nichts, wenn der Kern ein sauberes Backend-Gerüst liefert und die Plugins dann aus der Reihe tanzen.

Doch. Ich würde sagen, da liegt die klare Vorgabe. Plugins müssen halt nachziehen. Deswegen habe ich ja schon mal gesagt, würde es für mich auch eher Sinn machen, den "~1.7++" trunk pö-a-pö umzuschreiben, Seite für Seite. Dies kann sich einfacher und mehr an der Realität orientiert gestalten, als alles mühsam herauszuklauben und eine Skelett zu machen, was nachher genauso mühselig portiert werden muss. Und es bietet den unschätzbaren Vorteil, dass sich alle langsam umstellen können. Als Plugin Autor würde ich der Aussage, dass "das Backend-Template die Gestaltung komplett übernehmen" soll, nicht unbedingt zustimmen wollen. Wir sollten die Freiheit da nicht beschneiden wollen.

[yellowled]

Deswegen habe ich ja schon mal gesagt, würde es für mich auch eher Sinn machen, den "~1.7++" trunk pö-a-pö umzuschreiben, Seite für Seite.

Das mag sinnvoll klingen, beschleunigt aber die Sache in meinen Augen nicht wirklich, sondern zieht den Kern- und Plugin-Entwicklern Ressourcen ab, weil wir Gestalter bei diesem umschreiben nicht aktiv, sondern maximal beratend in puncto Markup helfen könnten. Das ist ineffizient.

Dies kann sich einfacher und mehr an der Realität orientiert gestalten, als alles mühsam herauszuklauben und eine Skelett zu machen, was nachher genauso mühselig portiert werden muss.

Das Skelett ist (natürlich nicht vollständig) bereits fertig. Und nein, man braucht kein vollständiges Abbild des Backends, um CSS zu schreiben, welches später das vollständige Backend gestaltet, wenn das Markup genau darauf ein wenig ausgelegt wird.

Und es bietet den unschätzbaren Vorteil, dass sich alle langsam umstellen können.

Es bietet auch den unschätzbaren Nachteil, dass so erstmal 2 Jahre wenig passiert und dann langsam mal über die Gestaltung diskutiert wird. Ich halte es psychologisch für wirkungsvoller, eine „So könnte das neue Backend aussehen“-Präsentation zu machen.

Als Plugin Autor würde ich der Aussage, dass "das Backend-Template die Gestaltung komplett übernehmen" soll, nicht unbedingt zustimmen wollen. Wir sollten die Freiheit da nicht beschneiden wollen.

Warum genau muss ein Pluginautor die Freiheit haben, die Ausgabe seines Plugins im Backend optisch zu gestalten?

YL

[Timbalu]

Ihhhh näää... "2 Jahre"... tztztz. Wir haben doch letztes Mal schon so lange gebraucht...!
Im Übrigen: Ein Gestalter der in Smarty Templates rumturnt, kann auch locker mit html+php umgehen!

Warum genau muss ein Pluginautor die Freiheit haben, die Ausgabe seines Plugins im Backend optisch zu gestalten?

"Because it is there!"
George H.L. Mallory

[onli]

Das ist Unsinn. Das Plugin kann nicht wissen, dass sich das rot in der Warnungsbox mit dem pinken Hintergrund des Adminbereichs beißt.

Zur Smartifizierung: Ich sehe eigentlich überhaupt kein Problem darin, einzelne Bereiche jetzt zu smartifizieren. Ich verstehe die Bedenken von Garvin nicht ganz: Wenn die php-Daten nur die Daten bereitstellen und das Smarty-Template die Gestaltung komplett übernimmt, warum sollte dadurch ein Wartungschaos entstehen? Es wird doch in erster Linie dadurch viel einfacher, Bugs in der Logik zu fixen, und Templates kann man doch genauso updaten.
Smartifizierung muss halt bedeuten, saubere Schnittstellen mit sauberen Code zu schaffen, sodass Templates in der Gestaltung völlig frei sind. Das würde Bereich für Bereich gehen, vll teste ich das am Wochenende bei einem simpleren Menü mal aus.

[yellowled]

Ein Gestalter der in Smarty Templates rumturnt, kann auch locker mit html+php umgehen!

Nein. Das ist ja gerade der Vorteil von Smarty: Es nimmt diesen ganzen PHP-Code weg, der uns nur unnötigt verwirrt, vor allem aber dafür sorgt, dass wir Fehler einbauen, die das Ganze noch weiter verzögern. Es hat ja einen Grund, weshalb dieses Projekt Smarty nutzt.

YL

[yellowled]

Wenn die php-Daten nur die Daten bereitstellen und das Smarty-Template die Gestaltung komplett übernimmt, warum sollte dadurch ein Wartungschaos entstehen?

Es geht, wenn ich das richtig erinnere, nicht um Chaos, sondern um Performance.

YL

[Timbalu]

Es geht, wenn ich das richtig erinnere, nicht um Chaos, sondern um Performance.

Darf ich auch mal?
Performance? Eben nicht unbedingt. Daran könnte man arbeiten. Ein Wartungschaos kann man ebenso verhindern. Aber man hat nicht mehr einfach die Freiheit, etwas tatsächlich zu verändern, bzw etwas ganz neues hinzuzufügen. Immer unter der Prämisse natürlich, dass man damit andere Admin Template z.T. funktionsunfähig setzen würde, weil deren Erwartungen nicht mehr erfüllt werden.

Der Punkt ist dabei der Anspruch, immer und überall kompatibel zu bleiben. Das zwingt den Daumen auf das Backend! Das ist ein (wichtiger) Gesichtspunkt, den Garvin sicherlich irgendwann mal aufgeben müssen wird. Das Wann ist da bedeutsam. Ich habe mir das Zitat damals rauskopiert, damit ich mich daran erinnere und messe, weil ich auch dann und wann dazu neige, den Zeitpunkt - wenigstens in Teilbereichen - für gekommen zu sehen.

@YL
Smarty ist auch PHP und verdeckt die Tatsache, dass beide mehr oder minder Templatesprachen sind, von denen die eine die andere übersetzt (compiliert). Ein Blick in eine der template_c Dateien genügt, um herauszufinden, dass womöglich ein einfaches PHP Template a la comments.inc.php schlichter und verständlicher wäre...

[onli]

Aber man hat nicht mehr einfach die Freiheit, etwas tatsächlich zu verändern, bzw etwas ganz neues hinzuzufügen.

Halte ich für falsch. Gib mir mal ein Beispiel. Wie genau geht ein altes Template kaputt, wenn man in der Schnittstelle eine neue Funktion hinzufügt?

Es geht, wenn ich das richtig erinnere, nicht um Chaos, sondern um Performance.

Gerade im Backend ist Performance vernachlässigbar. Klar sollte das nicht zutode laggen, aber die halbe Sekunde zusätzliche Ladezeit, die Smarty verursachen könnte, wäre in meinen Augen kein Problem. Das Backend wird ja viel seltener aufgerufen als das Frontend - im Frontend ist Performance entscheidend, und dort leisten wir uns Smarty ja auch.

Smarty ist auch PHP und verdeckt die Tatsache, dass beide mehr oder minder Templatesprachen sind, von denen die eine die andere übersetzt (compiliert)

Manchmal stimmt das. Aber Smarty ist eine Teilmenge. Man kann mit PHP viel mehr Unsinn machen, das nicht zu können hilft Nicht-Codern ungemein (bzw. geht es darum, wie sie das sehen, nicht wie du ;) )

[Timbalu]

Halte ich für falsch. Gib mir mal ein Beispiel. Wie genau geht ein altes Template kaputt, wenn man in der Schnittstelle eine neue Funktion hinzufügt?

Keine Ahnung. Vielleicht Änderungen am DB System mit Folgen und oder neue Funktionen die alte Funktionen und ihre Ausgaben verändern. (Ich persönlich könnte auch damit Leben, dass man irgendwann auch mal etwas kaputt macht, was zum Umstieg zwingt.) ...Vielleicht ist es ja auch nur die theoretische Möglichkeit.

... (bzw. geht es darum, wie sie das sehen, nicht wie du )

bin ja schon st.i!!

[yellowled]

Performance? Eben nicht unbedingt.

Ich habe nur zitiert, was ich als Grund erinnerte, das Backend nicht komplett zu smartifizieren, mehr nicht. 'tschuldigung, ich dachte, das sei deutlich gewesen.

Smarty ist auch PHP und verdeckt die Tatsache, dass beide mehr oder minder Templatesprachen sind, von denen die eine die andere übersetzt (compiliert).

Mir ist das Prinzip von Smarty ebenso bekannt wie das von Compilern. Das ändert nichts daran, dass Smarty eine stark vereinfachende Abstraktionsschicht ist, die mir als HTML/CSS/JS-Heini im Gegensatz zu nackten PHP-Templates eine Syntax vorsetzt, die ich halbwegs durchblicke.

Es geht nicht darum, dass es technisch gesehen nichts sensationell anderes ist. Es geht darum, dass es sich für mich (und die meisten reinen Frontendler) zugänglicher anfühlt und das Gefühl vermittelt, weniger Mist machen zu können. Das ist ein bißchen wie natives JS vs jQuery.

YL

[Timbalu]

Wie könnte man denn die hooks

Code: Select all

{serendipity_hookPlugin hook="backend_sidebar_entries" hookAll="true"}
{serendipity_hookPlugin hook="backend_sidebar_entries_images" hookAll="true"}
{serendipity_hookPlugin hook="backend_sidebar_admin_appearance" hookAll="true"}
{serendipity_hookPlugin hook="backend_sidebar_admin" hookAll="true"}

in so eine navigations select box zwingen?

Ui, diese 4 erinnern mich an einen anderen Thread, in dem es darum ging, in welche Abteilung die Plugins sich selbst einweisen. Da sind wir auch mittendrin stehengeblieben....

EDIT: Ersteres hat sich erledigt. Danke.

[Timbalu]

Alpha-3 ist auf GitHub verfügbar.
Das Fenster wird jetzt embedded, trotzdem ist die sidebar abwählbar und wird dann durch eine horizontale Selectbox-Leiste ersetzt.