brainstorming: dashboard template UI mit jquery + x

[yellowled]

Bisher ja..., aber es bietet ja eigentlich nichts (ausgenommen autoupdate), was nicht durch das BE sowieso schon bereitgestellt wird. Ersetzen kann ein Dashboard das Backend sowieso nicht und will das ja auch gar nicht.

Dann wäre aus meiner Sicht eher die Frage, ob man das Dashboard nicht fest ins Backend integriert.

YL

[yellowled]

Ich hab meinen bisherigen Ablauf mal geschrumpft...:

Code: Select all

 jQuery(document).ready(function($) {
 $("div#entrybox a.button").click(function () {$("div#entrybox div.boxed").slideToggle("slow");});
});
    <div class="dashboard dashboard_comments">
        <h3> {$CONST.COMMENT} </h3>
            {foreach from=$comments item=co name='foo'}            
            <div id="entrybox"> 
                <div class="blah" id="comment_{$co.id}">
                    <label class="x"> <a href="#colist_{$smarty.foreach.foo.iteration}" class="button"> Press Here</a> </label>
                    {body}
                    <div class="boxed">
                        <a name="colist_{$smarty.foreach.foo.iteration}"></a>
                        {detail+adminbox}
                    </div>
                </div>		
            </div><!-- #entrybox end -->
            {/foreach}
    </div>

Sorry, aber das ist kruder Unfug. Er enthält ein unsinniges label (ohne Formularelement), Links ohne Linktext (böse, böse), Du gibst Elementen, die über eine foreach-Schleife ausgegeben werden, eine nicht dynamische id (id muss unique sein) … das geht so nicht.

Ich habe mal versucht, zu erraten, worauf Du hinaus willst, und es so gebaut, dass es funktioniert und sogar screenreadertauglich wäre. Ich hoffe, das ist so ungefähr das, was Du im Sinn hattest – eben das ist mir leider nicht ganz klar.

http://jsfiddle.net/yellowled/9nuzZ/

YL

[Timbalu]

Dann wäre aus meiner Sicht eher die Frage, ob man das Dashboard nicht fest ins Backend integriert.

Tja, mein reden...

...das ist kruder Unfug...

Naja die form hatte ich mal weggeschrumpft zur besseren Sichtbarkeit, Links ohne Linktext kann ich im Beispiel nicht erkennen, Elemente bekommen {$co.id oder {$smarty.foreach.foo.iteration} beides sehr unique und sehr dynamisch... außerdem sollte das ja nur einen ungefähren IST Zustand darstellen... und noch keinen Versuch dies für die einzelnen Schlaufen klappbar zu machen.

Ich habe mal versucht, zu erraten, worauf Du hinaus willst, und es so gebaut, dass es funktioniert und sogar screenreadertauglich wäre. Ich hoffe, das ist so ungefähr das, was Du im Sinn hattest – eben das ist mir leider nicht ganz klar.

Jupp sehr schön! Vielen Dank!
Wobei das mit dem Umbau noch etwas dauert, weil nicht ganz so einfach strukturiert. Zum Beispiel gibt es ja innerhalb eines solchen Elements noch eine weitere Klappbox, die Auswahl checkbox Funktion usw.

[yellowled]

Links ohne Linktext kann ich im Beispiel nicht erkennen

Code: Select all

<a name="colist_{$smarty.foreach.foo.iteration}"></a>

hat keinen Linktext. Das ist genauso unbrauchbar wie die Links ohne bzw. mit leerem href-Attribut, die viele JS-Codeschnipsel verwenden. Nicht machen. (Ja, ich habe in meiner fiddle auch href="#"; sollte halt schnell gehen.)

YL

[Timbalu]

Das ist ein <a name nicht ein <a href !
Benötigen denn name attributes anchornamen auch einen linktext? Wozu?

Nach dem Versuch der Übernahme, schaltet mir $(this).siblings().toggleClass('visuallyhidden'); übrigens nun immer alle Zwillinge ab, brav für jeden Kommentar so weit so gut, aber das soll ja gar nicht. Nur boxed soll auf/zu-geklappt werden... Wenn ich das Ding wegnehme oder verändere klappt es gar nicht mehr.

[yellowled]

Benötigen denn name attributes anchornamen auch einen linktext? Wozu?

Stell Dir mal vor, Dir würde das vorgelesen. Du hättest keinen Schimmer, wozu der Link da ist. Im Übrigen kann man (zumindest in HTML5) den Anchor ja einfach um den kompletten darauf folgenden Inhalt wickeln.

Nur boxed soll auf/zu-geklappt werden...

Naja, dann darfst Du eben nur .boxed die Klasse zuweisen und sie auch nur dafür togglen.

Code: Select all

[…].siblings('boxed')[…]

YL

[garvinhicking]

Hi!

<a name> sollte man heutzutage nicht mehr unbedingt nutzen. Wenn es um Sprunganker geht kann man auch <div>s mit einer id=XXX versehen um per #XXX dahin zu springen. Alle heutzutage sinnvollen Browser sollten das unterstützen, so dass <a name> wirklich ein eher altes Relikt sein dürfte.

YellowLED, Du korrigierst mich wenn das falsch ist?

Grüße,
Garvin

[Timbalu]

Yeah! Das wars! Danke sehr!
Ich muss mich wohl doch mal intensiver mit diesem Zeug beschäftigen, da es ja irgendwie doch CSS mit event Charakter ist!

Das mit dem Vorlesen verstehe ich nun, doch frage ich mich trotzdem warum ein Programm überhaupt einen Anker vorlesen sollte...

[yellowled]

Wenn es um Sprunganker geht kann man auch <div>s mit einer id=XXX versehen um per #XXX dahin zu springen.

Das ist natürlich sehr, sehr richtig. (Betriebsblindheit, my ass.)

Zudem aber kann man jedem HTML-Element eine id zuweisen, nicht nur divs. Dabei immer beachten, dass eine id unique innerhalb eines HTML-Dokumentes sein muss. Gleichzeitig sind ids, wenn ich mich nicht irre, der performanteste jQuery-Selektor.

YL

[onli]

Das mit dem Vorlesen verstehe ich nun, doch frage ich mich trotzdem warum ein Programm überhaupt einen Anker vorlesen sollte...

Da hast du recht. Ein Element, dass im Textbrowser (und damit im Screenreader) keine Bedeutung hätte, muss man nicht sehen können.

[yellowled]

Ein Element, dass im Textbrowser (und damit im Screenreader) keine Bedeutung hätte, muss man nicht sehen können.

Das mag so stimmen, allerdings gibt es in Screenreadern auch die Möglichkeit, sich den Quellcode vorlesen zu lassen – das mag aber nun wirklich nur eine minimale Nutzergruppe betreffen.

Wichtig ist dennoch: Keine Links ohne Linktext (dann lieber den Linktext in ein span wickeln und dieses „verstecken“, etwa, falls man den Link mit einem background-image als Grafik dekoriert), keine Links ohne href-Attribut (man kann jedes HTML-Element mit jQuery klickbar und mittels tabindex auch per Tastatur fokussierbar machen) und keine named anchors (stattdessen id auf Element nutzen wie oben beschrieben).

YL

[Timbalu]

Hi

Ich habe soeben mal eine frühe Alpha version auf mein GitHub Repository gestellt, damit die eventuelle gemeinsame Entwicklung dokumentiert fortschreiten kann.
https://github.com/ophian/serendipity_event_dashboard

Über konstruktive Kritik, Ergänzungen, Wünsche, etc., würde ich mich freuen. Nörgelt nur nicht zu sehr an Farben oder soetwas herum, denn darum geht es vorerst nicht, auch wenn ich mir dazu so meine Gedanken gemacht habe.

Das Ganze ist mehr zu soetwas wie ein Proof-of-Concept geworden und an manchen Stellen noch nicht wirklich zu Ende gedacht.

Viel Spaß
Ian

PS. im help Container befindet sich anstelle wirklicher Hilfe eher soetwas wie ein Teil meines bisherigen Entwicklungs-Fortschrittes...
Manche Sachen sind annähernd fertig und weisen in die von mir gewünschte Richtung, andere nur zum Teil.

Falls Unklarheiten bestehen, bitte nachfragen, damit Aufklärung ins README oder weiter in diesen Thread kann.

[yellowled]

Über konstruktive Kritik, Ergänzungen, Wünsche, etc., würde ich mich freuen. Nörgelt nur nicht zu sehr an Farben oder soetwas herum, denn darum geht es vorerst nicht, auch wenn ich mir dazu so meine Gedanken gemacht habe.

Soll das Dashboard komplett das restliche Backend ersetzen? Sobald ich die Alpha in einer 1.6 installiert, sehe ich auf der Backend-Startseit nur Dashboard.

Verwendet man dazu nicht das derzeitige Standard-Admin-Template, hat dabei auch ganz generell irgendetwas nicht hin, aber ich hatte mir vorgenommen, kein Wort über die Gestaltung zu sagen. Du solltest es nur, wenn es vor einem eventuell zu ändernden Backend veröffentlicht werden soll, auch mit anderen Admin-Templates testen und Dich nicht darauf verlassen, dass jeder das Standard-Admin-Template verwendet.

Ein paar (generelle) Anmerkungen zum Markup:

* Versuche, semantische ids und classes zu verwenden – "user-menu-left-bottom" z.B. macht primär eine Aussage über die Position eines Elementes im Layout, die kann sich aber recht leicht ändern. Besser wäre da z.B. "user-menu-full-menu" oder so. Ich weiß, das klingt nach Nitpicking, aber es erleichtert später die Arbeit mit CSS enorm, weil man von der id auf die Funktion schließen kann und somit weiß, welches Element es ist, ohne ins Markup zu gucken.

* Man kann drüber streiten, ob der Einsatz der sections so korrekt ist, ich würde sie vermutlich in einen article packen. http://html5doctor.com/downloads/h5d-se ... wchart.png

* Sowas wie "Press here" ist kein guter Linktext, weil es nicht kommuniziert, was dann geschieht.

Bisschen was zu UI/UX:

* Ich würde beim aufklappenden Hauptmenu so erwarten, dass ich es klicken muss. Bei Tastaturbedienung funktioniert übrigens der Wechsel des auf/zu-Icons nicht. Noch irritierender ist es, wenn die ähnliche Geschichte bei "Toggle all" nicht beim hovern ausklappt, das ist inkonsistentes Verhalten, was nicht so schön ist. Der Benutzer erwartet halt, dass gleich aussehende Elemente gleich funktionieren.

* Generell fehlen :focus-Styles, was die Bedienung per Tastatur so richtig schwierig macht, weshalb ich darauf im Moment nicht weiter eingehe. Die Hilfefunktion finde ich so klasse.

* Das ist ein wenig eine persönliche Ansicht, aber ich halte nicht viel davon, Formularelemente zu stylen. Es ist bei vielen mehr oder weniger unmöglich, das crossbrowser hinzubekommen. Übel wird es, wenn einige Elemente gestaltet sind, andere aber den nativen Look des Browsers haben – das verwirrt potenziell, sieht aber meistens auch einfach nicht aus.

Generell finde ich den Ansatz klasse, könnte mir auch gut vorstellen, dass das auf Dauer mehr als ein Plugin wird. (Kein Wort rein zur optischen Gestaltung gesagt. Für einen Gestalter ist es hart an der Grenze zur Folter, das nicht zu tun.)

YL

[yellowled]

* Ich würde beim aufklappenden Hauptmenu so erwarten, dass ich es klicken muss.

Äh, was mir gerade auffällt: Bleibt das auch mal geöffnet, so dass man einen Link darin klicken kann?

YL

[Timbalu]

Soll das Dashboard komplett das restliche Backend ersetzen? Sobald ich die Alpha in einer 1.6 installiert, sehe ich auf der Backend-Startseit nur Dashboard.

Als Startpage vorerst ja. Nicht, wenn du arbeitest oder zur Startseite gehst. Das ist wie gesagt ein "proof of concept"... bei dem ich selbst nicht sicher bin, ob das ein gangbarer Weg ist.

Verwendet man dazu nicht das derzeitige Standard-Admin-Template, hat dabei auch ganz generell irgendetwas nicht hin, aber ich hatte mir vorgenommen, kein Wort über die Gestaltung zu sagen. Du solltest es nur, wenn es vor einem eventuell zu ändernden Backend veröffentlicht werden soll, auch mit anderen Admin-Templates testen und Dich nicht darauf verlassen, dass jeder das Standard-Admin-Template verwendet.

Ja das kann sehr gut sein und ist nur mit Dons Backend default template getestet. Alles andere steht noch in weiter Ferne. Deswegen gebe ich sotwas ja auch nicht einfach als update frei.

* Versuche, semantische ids und classes zu verwenden – "user-menu-left-bottom" z.B. macht primär eine Aussage über die Position eines Elementes im Layout, die kann sich aber recht leicht ändern. Besser wäre da z.B. "user-menu-full-menu" oder so. Ich weiß, das klingt nach Nitpicking, aber es erleichtert später die Arbeit mit CSS enorm, weil man von der id auf die Funktion schließen kann und somit weiß, welches Element es ist, ohne ins Markup zu gucken.

Genau, so ein generelles cleanup ist später wichtig! Da werde ich sicherlich noch auf dich zukommen, wenn es denn je zu etwas werden sollte. Oder du pusht mal deine Verbesserungen.

* Man kann drüber streiten, ob der Einsatz der sections so korrekt ist, ich würde sie vermutlich in einen article packen. http://html5doctor.com/downloads/h5d-se ... wchart.png

s.o.

* Sowas wie "Press here" ist kein guter Linktext, weil es nicht kommuniziert, was dann geschieht.

Stimmt, das ist ein Überbleibsel und muss sicherlich mal ein CONSTANT mit geeignetem Text werden.

* Ich würde beim aufklappenden Hauptmenu so erwarten, dass ich es klicken muss. Bei Tastaturbedienung funktioniert übrigens der Wechsel des auf/zu-Icons nicht. Noch irritierender ist es, wenn die ähnliche Geschichte bei "Toggle all" nicht beim hovern ausklappt, das ist inkonsistentes Verhalten, was nicht so schön ist. Der Benutzer erwartet halt, dass gleich aussehende Elemente gleich funktionieren.

Zum Hauptmenü sei gesagt, es hovert um zu zeigen (ob das so bleiben sollte weiß ich selbst noch nicht), und es bleibt bei click, ist aber jquery-seitig noch nicht zufriedenstellend mit dem Klappimage und dem Zusammenspiel von hover und click gelöst. Es zeigt aber was ich meine, ohne es 100% zu erfüllen.

"Toogle all" für bereits genehmigte Kommentare sollte nicht hovern, finde ich. Das stört IMHO nur. Ansonsten gilt das Gleiche wie für "Press here".

* Generell fehlen :focus-Styles, was die Bedienung per Tastatur so richtig schwierig macht, weshalb ich darauf im Moment nicht weiter eingehe. Die Hilfefunktion finde ich so klasse.

Ja focus fehlt vorerst noch. Gehört für mich zu cleanup, mehr am Ende.
In der Hilfe hätte ich gerne Ideen zum Content auch in der Frage ob zentral oder verteilt.

* Das ist ein wenig eine persönliche Ansicht, aber ich halte nicht viel davon, Formularelemente zu stylen. Es ist bei vielen mehr oder weniger unmöglich, das crossbrowser hinzubekommen. Übel wird es, wenn einige Elemente gestaltet sind, andere aber den nativen Look des Browsers haben – das verwirrt potenziell, sieht aber meistens auch einfach nicht aus.

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

Generell finde ich den Ansatz klasse, könnte mir auch gut vorstellen, dass das auf Dauer mehr als ein Plugin wird. (Kein Wort rein zur optischen Gestaltung gesagt. Für einen Gestalter ist es hart an der Grenze zur Folter, das nicht zu tun.)

Das dich das eventuell foltert dachte ich mir schon. Darauf konnte ich aber vorerst keine Rücksicht nehmen, da ich selber mit mir ringe, wie Wesentliches wie hervorgehoben werden kann und sofort ins Auge fällt. Da habe ich viel herumprobiert und immer wieder mal das Kleid ausgewechselt. An dieser Stelle eine geeignete Vorlage für Viele zu finden, ist bestimmt eher schwierig.

Wohlan. Beteilige dich.
Danke für die Antwort!

PS.
Dieses Konzept basiert auf kleineren Änderungen bzw fixes, die bereit in den Serendipity trunk eingeflossen sind. Wahrscheinlich wird man sogar eher auf 1.7 als Minimum setzen müssen, dann könnte man die Templates als {block}s verwenden und für das Dashboard vielleicht sogar das Smarty Caching verwenden.