brainstorming: dashboard template UI mit jquery + x

[yellowled]

Da werde ich sicherlich noch auf dich zukommen, wenn es denn je zu etwas werden sollte. Oder du pusht mal deine Verbesserungen.

Nö, mach mal, wie Du denkst. Es ist IMHO sinnvoller, wenn ich da über eine Beta oder so mal drübergucke.

"Toogle all" für bereits genehmigte Kommentare sollte nicht hovern, finde ich.

My 2 cents: Verzichte auf onhover-Popout komplett. Es hat keinen Mehrwert und kostet Dich nachher, wenn Du an die Tastaturbedienung gehst, wahrscheinlich einen 2. Event-Handler, also Code-Ballast.

* Das ist ein wenig eine persönliche Ansicht, aber ich halte nicht viel davon, Formularelemente zu stylen.

Ich weiß zwar gerade nicht was du meinst, du wirst aber sicherlich recht haben...

Wir haben z.B. diese prettyButton-Klasse, die bestimmte Buttons anders gestaltbar macht als andere. Genauer gesagt sind das (meistens) keine button-, sondern input[type=submit]-Elemente, aber egal.

Jedenfalls sind Formularelemente (input, textarea, button, vor allem aber: checkbox, radio, select usw.) schwierig bis unmöglich und z.T. nur mit fiesen Hacks crossbrowser einheitlich zu gestalten, sprich (praktisch): Es so hinzukriegen, dass etwa ein select in Firefox, Chrome, Safari, Opera und womöglich allen IEs gleich aussieht, ist nahezu unmöglich. Es muss aber auch gar nicht sein – es ist völlig okay, denn die Optik dieser Elemente ist meistens konsistent mit der UI des Browsers.

Mein pragmatischer Ansatz, diesem Sachverhalt zu begegnen, ist es, Formularelemente so wenig wie möglich zu gestalten.

An dieser Stelle eine geeignete Vorlage für Viele zu finden, ist bestimmt eher schwierig.

Ich empfehle nach wie vor für alles, speziell Frontend-Code von Plugins, aber auch Backend-Code von Plugins und generell, so wenig Gestaltung wie irgend möglich bzw. unbedingt notwendig. Das betriff vor allem Farben und Schriftarten und -größen, aber auch z.B. den Einsatz von Grafiken.

Das sind alles Elemente, die später mit möglichen Admin-Templates Inkonsistenzen verursachen und evtl. nur schwer gerade zu biegen sind.

Dazu eben das Übliche – möglichst keine Inline-Styles; JS nur so, dass es auch ohne JS funktioniert; usw.

YL

[Timbalu]

My 2 cents: Verzichte auf onhover-Popout komplett.

Ist das ein Quot diese für die Navi abzustellen? Das könnte ich mir auch gut vorstellen.

Mein pragmatischer Ansatz, diesem Sachverhalt zu begegnen, ist es, Formularelemente so wenig wie möglich zu gestalten.

Das verstehe ich. Ich habe ja beim Anpassen zunächst darauf geachtet, ersteinmal die alten Klassen etc möglichst weiterzuverwenden. Die alten prettybutton Sachen passten aber einfach schlecht. Deshalb habe ich sie (zunächst) leicht modifiziert.

Das sind alles Elemente, die später mit möglichen Admin-Templates Inkonsistenzen verursachen und evtl. nur schwer gerade zu biegen sind.

Ja - dazu gibt es 2 Dinge
1.

Not having Smarty in the backend is actually not due to performance. We could work around that. The real reason is that if we put core features in templates,
we will never be able to properly update the core with new elements, because once people write backend templates, all the output would be part of the template,
and we'd have a maintaineance nightmare...

I really hope that the backend could simply be "cleaned up" by default and not to outsource it as templates...

Regards,
Garvin

Das ist etwas wirklich Bedenkenswertes! Denn Serendipity is ein OS Produkt, dass nicht darauf abzielt auf allen Ebenen (und wir sprechen hier vom Backend) "Verkaufs- und Vorlagenfähig" zu sein.

Und 2.: Wir leben in Zeiten, die ein gewisses Maß an (Browser/Fortschritts)-Kompatibilität durchaus fordern können, speziell in einem Backend, dass in der Regel eher von Einem oder Wenigen benutzt wird. Ich bin einer von den NoScript Nutzern, aber dieser Software vertraue ich! (jetzt komme bloß keiner auf den Gedanken das gleich auszunutzen )

[Timbalu]

Bevor wir uns hier aber dialogisch zu sehr in Kleinigkeiten verstricken, hätte ich gerne noch mehr über Konzepte und dergleichen diskutiert. Mir selber scheint das noch nicht ganz gar gekocht, und ich lebe manchen Tag damit mich zu fragen, ob das so wirklich Sinn macht, oder wie es weitergehen kann.

So sehr ich auch den "Kleinkram" zur Fertigstellung begrüße, (also Matthias bitte nicht damit aufhören,) wäre es mir doch lieb noch ein wenig länger am Konzept zu verweilen. Ist es noch zu viel oder zu wenig an notwendig dargebotener Information u.s.w., noch nicht Schlicht genug, fehlende wichtige Ergänzungen, Verzahnung mit Backend, etc., etc.

[yellowled]

My 2 cents: Verzichte auf onhover-Popout komplett.

Ist das ein Quot diese für die Navi abzustellen? Das könnte ich mir auch gut vorstellen.

Sorry, den Satz verstehe ich nicht. Quot?

Das ist etwas wirklich Bedenkenswertes! Denn Serendipity is ein OS Produkt, dass nicht darauf abzielt auf allen Ebenen (und wir sprechen hier vom Backend) "Verkaufs- und Vorlagenfähig" zu sein.

Deswegen bauen wir ja den Prototypen für das neue Backend in mühevoll aus dem System geklaubten HTML, anstatt zu schreien, dass gefälligst alles smartifiert werden soll.

Wir leben in Zeiten, die ein gewisses Maß an (Browser/Fortschritts)-Kompatibilität durchaus fordern können, speziell in einem Backend, dass in der Regel eher von Einem oder Wenigen benutzt wird.

Ich weiß nicht, was das eine mit dem anderen zu tun hat, aber egal.

Bei progressive enhancement bzw. unobtrusive JS geht es nicht so sehr darum, was der Browser kann, zumal jQuery vieles davon im Vergleich zu nativem JS kompensiert. Es geht einfach nur darum, dass nach Möglichkeit eine Funktionalität nie von JS abhängen sollte. Das Bayes-Plugin ist ein tolles Beispiel dafür – Malte hat es gerade so geändert (oder sitzt zumindest dran), dass die Spam/Ham-Buttons auch ohne JS funktionieren.

Grundsätzlich sind wir da völlig einer Meinung, zumal es ohnehin mittlerweile so einen Ansatz gibt „Wenn nix geht, schmeiß JS drauf“, aber grundsätzliche Funktionen sollten immer möglichst ohne JS funktionieren. Das hat nichts mit alten Internet Explorern zu tun, es ist z.B. auch denkbar, dass eine JS-Datei einfach fehlerhaft oder nicht vorhanden ist – und dann fallen ggf. kritische Funktionen aus.

YL

[Timbalu]

Wahrscheinlich wollte ich Vote schreiben....

Zum anderen - heißt das mein "PoC" funktioniert nicht? Ich habe zuviel JS? Oder was?
Grundsätzlich ist alles ohne lauffähig, aber ohne ist es relativ sinnlos, weil man eben nicht alles gleich sehen will, zum Beispiel. Ansonsten verstehe ich nicht was dich zu deinen Ausführungen veranlasst.

[yellowled]

Zum anderen - heißt das mein "PoC" funktioniert nicht? Ich habe zuviel JS? Oder was?

Es funktioniert, aber aus meiner Sicht irritiert es mehr, als es „nützt”, deshalb würde ich auf das ausklappen bei hovern verzichten. Ausklappen auf Klick/Taste reicht völlig, das meinte ich mit „Mehrwert“. Ich finde popout-on-hover hier nicht nützlich.

„Zuviel JS“ ist natürlich sehr relativ, zumal wir ohnehin jQuery mit dabei haben – die gängige Argumentation ist ja immer, bei den heutigen Bandbreiten usw. usf., aber es geht eben nicht nur um das downloaden von Assets, sondern auch um das Seitenrendering.

Wenn man den Hammer „eye-candy mit jQuery“ einmal in die Hand genommen hat, dann sieht schnell alles wie ein Nagel aus. Ich bin auch sehr dafür, das s9y-Backend in Zukunft unglaublich sexy zu machen, aber kein noch so schöner Effekt ist es wert, wenn das Backend dadurch langsam wird. Und natürlich ist jeder Schnippsel JS potenziell eine Perfomance/Rendering-Bremse, trotz minifizieren.

Durch HTML5 kommen wir immer öfter in die Situation, JS „unter der Haube“ zu verwenden, also für den Benutzer nicht offensichtlich. Wir benutzen den HTML5 shim, um die neuen semantischen Elemente in alten Browsern nutzbar zu machen. Wir benutzen Modernizr für feature detection und Polyfills, um alten Browsern Funktionalität beizubringen.

Nimm mal 2k11 – das hat neben (einem customized build von) Modernizr inklusive HTML5 shim noch:

* iOS Orientationchange, um einen lästigen Bug auf iOS-Geräten zu fixen
* Respond, um @media-Queries in IE6-8 zu nutzen
* FitVids, damit z.B. YouTube-Videos responsive werden
* einen Polyfill für das placeholder-Attribut
* einen Polyfill für das details-Element
* accessifyHTML5, um WAI-ARIA landmark roles dynamisch zuzuweisen (was Browser bald nativ machen werden)

… und dann habe ich noch nichts gemacht, was optische Verschönerung wäre, sondern nur Krempel nachgerüstet, den bestimmte Browser nicht von Hause aus können. Mittlerweile lädt es immerhin die ersten beiden nur, wenn sie benötigt werden, und man könnte sicherlich bei den letzten dreien diskutieren, ob das sein muss. Trotzdem ist das ganz schön viel JS für ein Template …

Grundsätzlich ist alles ohne lauffähig, aber ohne ist es relativ sinnlos, weil man eben nicht alles gleich sehen will, zum Beispiel.

Es geht nicht so sehr um sinnvoll bei unobtrusive JS, eher um zugänglich. Es ist durchaus möglich, ein solches "collapsible element" so zu bauen, dass es bei deaktiviertem JS unerreichbar versteckt bleibt. Dass es bei abgeklemmtem JS viel Platz frisst und nicht so aussieht wie mit JS ist vollkommen okay.

YL

[Timbalu]

Ja. (Im Übrigen war das auch schon heute Morgen weg.)
Ich habe viel zu viel. Aber da ich auf dem alten Backend aufsetze musste so einiges mitgeliefert bzw modifiziert werden.

Ich erinnere hier aus gegebenenem Anlass nochmal an den eigentlichen Ausgangspunkt und Grund dieser interessanten Ausführungen!
https://github.com/ophian/serendipity_event_dashboard

Verbunden mit der Bitte dies auf breiterer Basis zu testen und noch mal über zugrundeliegende oder unberücksichtigte Konzepte zu sprechen.

Viel Spaß
Ian

[Timbalu]

Ich habe gerade Alpha-2 released
https://github.com/ophian/serendipity_e ... ard#readme

Man könnte es auch Beta nennen, aber solange ich nicht annähernd weiß, was eventuell noch an Arbeit anfällt bleibt das auch so.

Immer noch hätte ich gerne ein paar "todesmutige" Tester.
(Da sollte aber nichts kaputt gehen, nein nein!)

[onli]

Feedback:
Schön ist, wie der Update-Notifier sich in das Dashboard einbindet, da funktioniert die Gestaltung. Auch die einzelne Box bei Draft ist sauber und klar, was man damit machen kann.

Die Hilfe wirkt so wirklich schön.

Ich war ziemlich irritiert, als das Plugin sich über das Backend gelegt, also die Navigation ausgeblendet hat. Ich habe auch nicht direkt gesehen, wie man wieder zurück kommt.
Die eingeklappte Navigation finde ich unglücklich.

Zum einen hast du dir Gedanken wegen der Farben gemacht, zum anderen ist es vorläufig, ich finde, dass du dir da durchaus jetzt schon Hinweise von YL geben solltest. Es erschlägt einen zuerst ziemlich.

Das liegt aber nicht allein an den Farben, sondern auch an den vielen Boxen. Mir wird nicht direkt klar, welche Box wofür ist. Pending approval ist über Comments, die Buttons darunter sehen aber fast aus wie Tabs, vor allem das Spamblock: Serendipity-label vor den beiden Buttons.

Am Ende zugefügt: Jetzt, nach etwas Gewöhnung, wirkt auch diese Ansicht nicht mehr so erschlagend (obwohl ich sie immer noch wirr finde). Es ist wohl vor allem unerwartet, was eine Abwehrreaktion hervorruft.

Viel besser gefiel es mir, nachdem ich den Link "Frontpage" gefunden habe. Es ist übrigens nicht klar, dass der in den Adminbereich führt und dort das Dashboard wie üblich integriert ist.
Dadurch, dass hier der ganze obere Block wegfällt, ist die Übersicht viel einfacher - und es sind einige Farben weniger. Warum wie das Hilfe-Icon hier ausgeblendet?

Trotzdem wirkt es noch etwas wie ein Fremdkörper, du solltest YLs Rat beherzigen und es so bauen, dass es sich in das Admin-Backend eingliedert.

Die "Toggle all"-Funktion bei Comments wirkt auf mich nicht rund. Vll würde es schon reichen, den Button an das Comments[5] zu stellen, aber auf mich wirkte der Block erstmal nutzlos. "Letzte Kommentare" wäre imho ein passenderer Titel. Oder: Warum nicht einfach das + neben Comments [5] setzen und den Titel klickbar machen?

Wenn man die Kommentarliste übrigens initial ausblendet, kann man die "Pending approval"-Liste auch unter die Kommentarliste setzen, und es wird klarer, was genau da moderiert werden kann (Kommentare).

Zu der Liste selbst: "Add Comment #57 to selection" ist mir zu verbose, fände es schöner, wenn das alleine durch die Gestaltunf klar wird. Das Datum im Uhricon zu verstecken wird bisher nirgendwo sonst so gemacht, glaube ich, und ich sehe nicht den Sinn davon.

----------------------

Generell:
Was genau ist das jetzt? Als Dashboard, das sich über das Adminpanel legt, ist es fast ein Entwurf eines neuen Adminbereichs. Ich fände es zumindest sehr unglücklich, wenn man erst das sehen würde und dann zurück in ein normales Adminpanel kommen müsste, diesen Bruch sollten wir vermeiden.

Als Dashboard an sich ist es nicht soo viel mehr als vorher, und das finde ich ganz gut: Boxen können nebeneinander liegen, du hattest in diesem Thread mal geschrieben, dass man sie frei positionieren können soll, und Elemente können eingeklappt werden. Aus der Hilfebox könnte man eine komplette s9y-Hilfe machen, wenn man eine für sie passende Doku schreibt.
Dafür bricht zum einen das Dashboard mit dem Design als ganzes mit dem Adminbereich, und die einzelnen Listen mit den anderen Listen im Adminbereich. Das finde ich bei den Artikellisten gut, weil das rein subjektiv schlicht besser aussieht als zuvor, bei der Kommentarliste ist es zusammen mit der Aufklappfunktion mir zu viel und ich finde es auch nicht schön.

Ich plädiere für:
* Design, das sich anpasst
* Nicht die Adminpanelersetzung, sondern das Dashboard wie gehabt als Untermenü
* Wenn man schon diesen Boxen-JS-Weg geht (statt Smarty-Html), dann sollte man die Boxen auch frei vergrößern und positionieren können
* Hilfefunktion ausbauen, bzw Hilfe aufbauen und über diese Box in ganz s9y (wie wäre es mit einer integrierten Feedback-Funktion?)
* Das Design und Konzept der Pending-Approval-Box überarbeiten

Insgesamt bin ich eher positiv überrascht und gleichzeitig zwiegespalten: Als einfacher Dashboardersatz könnte das sehr gut funktionieren und ist es eine ordentliche Weiterentwicklung/Neuentwicklung, aber die Adminpanelersetzung hat das Zeug zum nie-endenden Mammutprojekt, das ich ein bisschen befürchtet habe, und du solltest dir beim Design helfen lassen.

[Timbalu]

UFF! Danke dir!

Boxing: Praktischerweise sieht man ja erst worum es geht, wenn man zum Einen tatsächlich mindestens einen Draft und einen Future Artikel in der Röhre hat, sowie zum anderen S9y-Core und Plugin Updates bereitstehen.

Navigation: Die Navigation würde halt viel Platz wegnehmen, selbst wenn man sie segmentiert horizontal ausgeben würde.

"Ko-color-res": Zu den Farben sag ich erstmal nix, da sie wie gesagt ja durchaus vorläufig sind und mein Hauptaugenmerk darauf lag, wie ich bestimmte Dinge möglichst sofort in die Aufmerksamkeit bringe. Optimal ist das so sicher noch nicht!

Backend-Link: Der Link ins Backend ist oben links ja prominent gesetzt, doch ich verstehe auch, dass man sich daran erst gewöhnen muss. Diesem Link lange Erklärungen hinzuzufügen, ist da IMHO eher schädlich... hmmm... lass uns darüber noch ein wenig nachdenken.

Help Box: Ich weiß es nicht. Das ist ja noch ziemlich unausgegoren. Was will man da viel helfen? Besonders auf der schlichteren Unterseite...? Auf so einer Hauptseite würde sie Sinn machen (gefüllt natürlich).

First-in: Also weg mit der Einzelseite meinst du ganz generell?

Kommentare: Ja "letzte Kommentare" wäre viel besser. Allerdings bitte ich zu bedenken, dass ich dafür nicht der Übeltäter bin und es einfach schon so war (glaube ich) und jetzt nur smartifiziert (u.a.) wurde. Ich frage mich selbst schon eine ganze Weile, warum die Kommentare da überhaupt benötigt werden... Zum Arbeiten doch eigentlich nur für Bayes, eventuell... Die "pending comments" habe ich natürlich obendrauf gesetzt, da sie es sind, die vordringlich zur Bearbeitung anstehen. Das Schicke aber ist, dass das (Einschränkung: siehe unten) jeder selber bestimmen kann!

Comment-Header-Datum: Diese Sache mit dem Datum im "clock" kam mir, da der Header sonst ingesamt sehr lang geworden wäre. Mit kleineren Browserfenstern hätte das zu schnell zu häßlichen Umbrüchen geführt. Deshalb habe ich das gestern oder heute gerade erst geändert.

Entwurf und Umbruch: Ja, das ist es auch was mich umtreibt...

Position: Das freie Positionieren hatte ich mal, aber dann waren alle beteiligten Segmente einzeln und untereinander. Ich fand es zum Schluss einfach besser und klarer, die beiden Entries und die beiden Updates semantisch zu je einer Reihe zusammenzufassen. Sie selber benötigen einzeln auch nur die Hälfte des Platzes. Insofern war das eher zwangsläufig. Ja und das beschränkte den freien flow natürlich etwas.

Erfahrungen: Das mit dem Zwiegespalten geht mir auch so... Vielleicht aber lebst du mal ein Weilchen damit und schaust dann was die tägliche Erfahrung dazu weiter sagt... Vielleicht bekommen wir ja noch mehr Stimmen, die das Ganze noch weiter verdichten.

Ausblick: Da das Ganze auf GitHub liegt, kann man ja auch schnell einen Fork machen und mal seine ganz eigene Gestaltung ausprobieren. Eine gemeinsame Verdichtung und Verbesserung wäre mir recht!

[yellowled]

Zum einen hast du dir Gedanken wegen der Farben gemacht, zum anderen ist es vorläufig, ich finde, dass du dir da durchaus jetzt schon Hinweise von YL geben solltest.

Mein Hinweis ist (generell und für alle Backend-Komponenten von Plugins) möglichst keine Farben zu verwenden. Wenn überhaupt, dann kann man z.B. für Meldungen die typischen rot/grün-Töne verwenden, aber auch da wären die serendipity_msg_*-Klassen vorzuziehen.

Genauso empfehle ich, Abstand zu halten von:

* Schriftarten und -größen
* nicht flexiblen Dimensionen
* Rahmen (man kann allerdings Rahmen so angeben: 'border: 1px solid;' – das ist eher brauchbar, wird aber in den meisten Fällen schrecklich aussehen)
* so ziemlich allem aus dem CSS3-Hübschibunti-Bereich – border-radius, box-shadow usw. usf.

All das sollte normalerweise das Admin-Template regeln. Ich weiß, tut's im Moment in den wenigsten Fällen. Also bitte möglichst alle Styles überschreibbar in ein Stylesheet, das dann in die serendipity.css inkludiert wird, packen und nicht inline über style="…" – im Namen aller aktuellen und zukünftigen s9y-Gestalter sage ich jetzt schon danke.

Was genau ist das jetzt? Als Dashboard, das sich über das Adminpanel legt, ist es fast ein Entwurf eines neuen Adminbereichs.

Für den Moment kann es nicht mehr als ein Plugin sein. Ich stimme Malte zu, dass es sich als solches integrieren sollte. Später kann man es sicher anders in ein umgestaltetes Backend integrieren. Der derzeitige Enwurf (der komplett in den Kinderschuhen steckt) sieht so ein Dashboard auch vor.

* Wenn man schon diesen Boxen-JS-Weg geht (statt Smarty-Html), dann sollte man die Boxen auch frei vergrößern und positionieren können

„Frei“ wird da relativ, aber „wie Plugins/Themes“ wäre vielleicht gut.

YL

[yellowled]

Die Navigation würde halt viel Platz wegnehmen, selbst wenn man sie segmentiert horizontal ausgeben würde.

Spricht etwas dagegen, ein select als Navigation zu verwenden?

Zu den Farben sag ich erstmal nix, da sie wie gesagt ja durchaus vorläufig sind […]

Hihi, so versuche ich das auch immer. Funktioniert nicht, kann ich Dir so sagen. In dem Moment, wo Du einen Entwurf vorzeigst, stürzen sich alle auf die Farben. Ist natürlich.

YL

[Timbalu]

Also bitte möglichst alle Styles überschreibbar in ein Stylesheet, das dann in die serendipity.css inkludiert wird, packen und nicht inline über style="…"

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

„Frei“ wird da relativ, aber „wie Plugins/Themes“ wäre vielleicht gut.

Ist es auch schon. Und es funktioniert! Im Gegesatz zu früher. (Natürlich unter den gemachten Einschränkungen (Position)).

[Timbalu]

Spricht etwas dagegen, ein select als Navigation zu verwenden?

Nein. Gar nichts. Außer jemand mag select-boxen nicht. 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?

Hihi, so versuche ich das auch immer. Funktioniert nicht, kann ich Dir so sagen. In dem Moment, wo Du einen Entwurf vorzeigst, stürzen sich alle auf die Farben. Ist natürlich.

Sehr wahr! Tja und deswegen werde ich weiterhin von "vorläufig" sprechen und den Sturz ertragen lernen. Am Ende landen alle im Farbbad!

[onli]

Da sieht man halt, wie wichtig die Farben sind ;)
Sie sind nunmal wirklich ein ernstzunehmender Faktor. 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.

First-in: Also weg mit der Einzelseite meinst du ganz generell?

Ja. Was soll ihr Sinn sein? Ihr einziger Vorteil ist, dass die Navigation verschwindet, und Vorteil ist dafür das falsche Wort.

Backend-Link: Der Link ins Backend ist oben links ja prominent gesetzt, doch ich verstehe auch, dass man sich daran erst gewöhnen muss. Diesem Link lange Erklärungen hinzuzufügen, ist da IMHO eher schädlich... hmmm... lass uns darüber noch ein wenig nachdenken.

Auch das Problem würde wegfallen, wenn man diesen Bruch gar nicht macht.

Ist es auch schon. Und es funktioniert!

Ich konnte nichts bewegen. Oder hätte ich was umpositioneren gekonnt und habe es nicht gesehen - oder hast du den Code dafür gerade erst commitet? Ich meine mit umpositionieren: Platzieren per Drag & Drop.