Erweiterung der Navbars

[peuter]

Ich habe mal die Navbars mit ein paar aus meiner Sicht sinnvollen Ergänzungen versehen.
Es besteht nun zum Einen die Möglichkeit mehrere Navbars gleichzeitig zu benutzen, also z.B. eine Obere und eine Linke. Und zum anderen kann man diese einzeln Seitenweise ab- und anschalten.

Da ein Beispiel mehr sagt als tausend Worte habe ich meine Beispiel-Config fürs Metal-Design mal entsprechend erweitert, damit man sehen kann, wozu das gut sein kann.

Alles zu finden im SVN.

Gruß
Tobias

[Chris M.]

Sehr schön!!!

Mir fallen dabei zwei mögliche Verbesserungen auf:

• Das Einfahren der Hauptseiten durch den <pagejump> hat dazu geführt, dass eine frühere Annahme nicht mehr gilt: das alte und neue Seiten nebeneinander liegen (das logische Konstrukt ist eigentlich ein horizontaler Baum von Seiten: links der Parent und rechts das Child. So kann man auch logisch mehrere Levels nach oben springen. Durch <pagejump> darf man nun aber zwischen Childs auf einer Ebene - oder gar deren Grandchildren - wechseln...)
  => Das ist eigentlich ein templateengine-Bug und wird nur durch das Beispiel richtig schön demonstriert
• Wird durch eine Seite eine Navbar eingeblendet, die es dort noch nicht gab (einfach beim Metal-Demo von "Start" nach "KNX" wechseln und zurück) erscheint die Navbar einfach.
  Ich schätze es wäre optisch ansprechender, wenn die von ihrer jeweiligen Seite "eingefahren" wird. (Das wäre auch konform zu dem Ziel, die - je nach Config-Parametern - vom User per Handle "einziehbar" zu gestalten, vgl. Android-Menüleiste)

[JuMi2006]

Eine Sache leuchtet mir jetzt nicht 100% ein.
Für die navbar gibt es jetzt target, label und name.

target ist klar, das ist ja quasi die id.

label wird bei der Navbar auf links nicht genutzt, dafür name

name wird bei der Navbar oben nicht genutzt, dafür label

Das sorgt ein wenig für Verwirrung, sollte eigentlich auch mit nur einem Element zu machen sein oder ?

Bzgl. usability auf mobilen Geräten stellt sich mir die Frage ob bottom für navbar nicht auch interessant sein kann? Das wäre z.Zt. noch broken, evtl. sogar centered Elemente ?

So ich will nicht nerven - ihr habt genug Baustellen


Danke und Gruß Mirko

[mclb]

Passt jetzt hier nicht so ganz 100%ig, aber nachdem ich hier gelesen hab, dass die CV weiß welche Seite über/unter/neben der aktuellen Seite kommt, wäre dann eine Navigation wie im EibPort möglich? Also z.B. ein Wisch am Bildschirm von oben nach unten und man kommt auf die Seite über halb.

Sowas würde meine Frau echt glücklich machen. ;-)

[Chris M.]

wäre dann eine Navigation wie im EibPort möglich? Also z.B. ein Wisch am Bildschirm von oben nach unten und man kommt auf die Seite über halb.

Die Navigation des EibPort kenne ich nicht.

Für Touch Geräte hatte ich mir durchaus gedacht, das Hoch/Runter-Wischen auf der Seite Scrollen sollte und ein Links/Rechts Wischen einem Vor/Zurück entsprechen würde.

[mclb]

Aber ich will ja nicht auf die vorherige Seite, wenn ich von links nach rechts Wisch, sondern auf die Seite, die lt. meiner Seiten Struktur links daneben ist.
Wenn ich von rechts nach links Wisch auf die Seite rechts neben der Aktuellen.
Wenn ich von oben nach unten wisch auf die übergeordnete.
Von unten nach oben wird wohl schwierig, wenn mehrere Children gibt.

Die Frage ist halt, würd sowas überhaupt gegen?
Ist ja im Prinzip auch egal, ob das mit dem Finger, oder der Maus gemacht wird, im Endeffekt müsste man den Mausklick-Event abfangen, während des Maus bewegen die beiden Seiten mitmoven und beim Maus loslassen die neue Seite fertig laden.

Bitte killt mich jetzt nicht für die Frage ;-)

[Chris M.]

Du musst die Hierachie drehen. Die übergeornete Seite ist links, die Kinder rechts.
Oben/Unten hat keine Bedeutung (man könnte sich hier höchstens gleichwertige Seiten, also Geschwister, vorstellen)

Damit ist ein Aufstieg in der Hierachie per Rechts-Wisch (also die linke Seite zeigen) theoretisch möglich.
Ein Links-Wisch zum Kind wird dagegen schwierig - was soll passieren, wenn eine Seite mehrere Kinder hat?
Per Hoch-/Runter könnte man theoretisch zwischen Geschwistern wechseln - nur beißt sich das von der Bedienung mit dem normalen Scrollen, wenn eine Seite größer als der Bildschirm ist. (Und es beißt sich mit der internen Struktur im Browser, der kann nur Links/Rechts...)

Von daher sehe ich den Rechts-Wisch (= linke Seite) sinnvoll und hatte den intern schon immer eingeplant.

Da durch den <pagejump> aber die Baum-Struktur durch die Shortcuts in ihrer Logik etwas zerstört wird, würde ich das ganze eben umdeuten in History Vor- und zurück. Für den User sollte sich das dann ganz natürlich anfühlen.
Das sollte nebenbei auch leichter zu implementieren sein...

[peuter]

Eine Sache leuchtet mir jetzt nicht 100% ein.
Für die navbar gibt es jetzt target, label und name.

target ist klar, das ist ja quasi die id.

label wird bei der Navbar auf links nicht genutzt, dafür name

name wird bei der Navbar oben nicht genutzt, dafür label

Das sorgt ein wenig für Verwirrung, sollte eigentlich auch mit nur einem Element zu machen sein oder ?

Ein wenig durcheinander ist das schon. Ich brauchte für die Top-Navbar eine Möglichkeit einen Pagejump ohne Text, also nur mittels Icon darzustellen. Daher musste ich den Namen hier komplett ausschalten, da dieser sonst immer ausgegeben wird, auch wenn man das name-attribut weglässt. Wenn man da nun einen Text möchte, muss man den im Label mit angeben.

Aus meiner Sicht wäre es sinnvoller, wenn der Pagejump seinen Namen nur anzeigt sofern auch einer in der config deklariert worden ist, so hätte der Anwender größte Freiheit um das Aussehen des pagejumps zu bestimmen. Aber da das eine ziemlich grundsätzliche Änderung ist und ich vielleicht mit meiner Meinung alleine da stehe, stelle ich die hier erstmal zur Diskussion.

Bzgl. usability auf mobilen Geräten stellt sich mir die Frage ob bottom für navbar nicht auch interessant sein kann? Das wäre z.Zt. noch broken, evtl. sogar centered Elemente ?

Die bottom & right navbars hab ich, mangels Bedarf, noch garnicht getestet. Muss ich mir mal angucken.

[mclb]

@Chris: Danke für die ausführliche Erklärung, klingt logisch.

[peuter]

Das Einfahren der Hauptseiten durch den <pagejump> hat dazu geführt, dass eine frühere Annahme nicht mehr gilt: das alte und neue Seiten nebeneinander liegen (das logische Konstrukt ist eigentlich ein horizontaler Baum von Seiten: links der Parent und rechts das Child. So kann man auch logisch mehrere Levels nach oben springen. Durch <pagejump> darf man nun aber zwischen Childs auf einer Ebene - oder gar deren Grandchildren - wechseln...)
=> Das ist eigentlich ein templateengine-Bug und wird nur durch das Beispiel richtig schön demonstriert

Hm da fehlt mir noch das Verständnis, was bei dem Seitenwechsel intern tatsächlich passiert. Ich verstehe momentan nocht nichtmals wo da genau der Bug liegt. Ich habe nur gesehen, dass manchmal beim Seitenwechsel, die Seiten die Animation irgendwie anders aussieht, bzw. garnicht ausgeführt wird und die Seiten einfach erscheinen und nicht "reinfliegen".
Meinst Du das?

Ich schätze es wäre optisch ansprechender, wenn die von ihrer jeweiligen Seite "eingefahren" wird. (Das wäre auch konform zu dem Ziel, die - je nach Config-Parametern - vom User per Handle "einziehbar" zu gestalten, vgl. Android-Menüleiste)

Das macht Sinn und das hab ich gleich mal implementiert. Damit man das später auch für andere Sachen verwenden kann, hab ich das in eine Funktion [fadeNavbar()] ausgelagert.

[Chris M.]

Aus meiner Sicht wäre es sinnvoller, wenn der Pagejump seinen Namen nur anzeigt sofern auch einer in der config deklariert worden ist, so hätte der Anwender größte Freiheit um das Aussehen des pagejumps zu bestimmen. Aber da das eine ziemlich grundsätzliche Änderung ist und ich vielleicht mit meiner Meinung alleine da stehe, stelle ich die hier erstmal zur Diskussion.

Laut Code zeigt der Pagejump den angegebenen Namen an, oder wenn nicht existent dann - quasi als Fallback - das Target.

=> Würde es das Problem lösen einen leeren String als Name mit anzugeben?
(Wahrscheinlich ja, aber wahrscheinlich würde der Editor das zerstören, da der nicht wissen kann ob der String nun bewusst oder unbewusst leer ist...)

Was man aber sicher machen kann, ist eine zusätzliche Option dem Pagejump mit zu geben...

Hm da fehlt mir noch das Verständnis, was bei dem Seitenwechsel intern tatsächlich passiert. Ich verstehe momentan nocht nichtmals wo da genau der Bug liegt. Ich habe nur gesehen, dass manchmal beim Seitenwechsel, die Seiten die Animation irgendwie anders aussieht, bzw. garnicht ausgeführt wird und die Seiten einfach erscheinen und nicht "reinfliegen".
Meinst Du das?

Ja. Wenn man jetzt per Pagejump zwischen den Seiten wechselt, insb. hin- und her, springen manche, manche bewegen sich, manche springen beim ersten mal und bewegen sich bei folgenden aufrufen, etc.

Hintergrund ist, dass alle Seiten nebeneinander im DOM liegen (genauer: im DOM natürlich hintereinander, aber per Darstellung nebeneinander...) und zwar der Page-Baum serialisiert. (Am besten die Demo-Config mal im FireBug ansehen, da sieht man das ganz schon...). Die Seiten die nicht im aktuellen Pfad liegen (also id_0 bis zur aktuellen) sind nicht dargestellt, da ihnen die Klasse "pageActive" fehlt.
So lässt sich nun wunderbar zwischen dieser und allen übergeordneten Seiten horizontal scrollen (vgl. style="left:..." bei "pages" unter "main"). Auch zur Sub-Seite kann man schön scrollen, die wird einfach per "pageActive" darstellbar gemacht, d.h. liegt nun rechts außerhalb des sichtbaren und nun kann man nach rechts scrollen.

Durch den Wechsel zwischen Kindern bzw. Cousinen kommt diese Logik nun etwas durcheinander...

Das macht Sinn und das hab ich gleich mal implementiert. Damit man das später auch für andere Sachen verwenden kann, hab ich das in eine Funktion [fadeNavbar()] ausgelagert.

[peuter]

Die Seiten die nicht im aktuellen Pfad liegen (also id_0 bis zur aktuellen) sind nicht dargestellt, da ihnen die Klasse "pageActive" fehlt.

So langsam fange ich an das zu verstehen!
Wenn ich jetzt von vorne herein alle page-elemente mit der Klasse "pageActive" versehen, kann beliebig gescrollt werden, richtig?
Gibt es da eventuell Performance-Gründe, die dagegen sprechen, oder wäre das eine akzeptable Lösung?

Spätestens, wenn ich alle Seiten einmal angeklickt habe, haben alle pages die pageActive Klasse, die wird nämlich nur gesetzt und nirgendwo wieder entfernt (Bug oder Feature?).

[Chris M.]

So langsam fange ich an das zu verstehen!
Wenn ich jetzt von vorne herein alle page-elemente mit der Klasse "pageActive" versehen, kann beliebig gescrollt werden, richtig?
Gibt es da eventuell Performance-Gründe, die dagegen sprechen, oder wäre das eine akzeptable Lösung?

Performance mag sein (insb. bei mobilen Geräten, da die nun eine Bitmap von Seitenanzahl * Bildschirmbreite im RAM halten müssten...).

Aber wesentlich schlimmer: Das gibt Darstellungsfehler!

Stell Dir einfach vor, Du willst bei einer Seite auf die 2. Children-Seite wechseln (und das Erste Children hat gar noch viele Sub-Seiten...) - das Ergebnis wäre nun eine ganz lange Scroll-Orgie nach rechts, da das erste Children+Sub-Seiten überscrollt werden muss

Spätestens, wenn ich alle Seiten einmal angeklickt habe, haben alle pages die pageActive Klasse, die wird nämlich nur gesetzt und nirgendwo wieder entfernt (Bug oder Feature?).

Ich sehe es gerade mit schrecken. => Schlimmer Bug! (Und Regression. Release macht das noch richtig...)

So kann man genau den Darstellungs-Fehler sehen, den ich oben beschrieben habe. (Hinweis: der Page-Tree wird von unten nach oben im DOM abgelegt, da's für die Darstellung egal ist...):

• Öffne das Widget-Demo
• Klicke auf der Start-Seite nach und nach alle direkten Sub-Seiten (also Iframe Test, Flavour Test, ...) an
• Am Schluss noch mal die oberste Sub-Seite (Infotrigger: Erweitert...) anklicken - einem wird von dem Gescrolle nun schlecht...

[peuter]

Ich sehe es gerade mit schrecken. => Schlimmer Bug! (Und Regression. Release macht das noch richtig...)

Ok das war wohl wieder mal meine Schuld . Habs gefixt. Ich habs erstmal so wieder hergestellt, wie es vorher war. Es werden alle Seiten deaktiviert (also die pageActive-Klasse entfernt), die nicht im Pfad zwischen der aktuellen Seite und der Root-Seite liegen.
Auch wenn das so nicht mehr ganz passt, da man ja jetzt mit den pagejumps beliebig im Page-Tree herumspringen kann. Aber da hab ich erstmal auch keine Lösung für.

[peuter]

Wenn man jetzt per Pagejump zwischen den Seiten wechselt, insb. hin- und her, springen manche, manche bewegen sich, manche springen beim ersten mal und bewegen sich bei folgenden aufrufen, etc.

Ich habe mich jetzt nochmal in Ruhe mit dem Thema beschäftigt und würde folgende Lösung vorschlagen:
* Einblenden einer neuen Seite von links nach rechts, wenn ich mich in der Browser-History zurück bewege oder mich zu einem direkten Vorfahren der aktuellen Seite bewege
* Einblenden von rechts nach links: in allen anderen Fällen

Nachdem jetzt absolut nicht mehr vorrausgesagt werden kann zu welcher Seite der nächste Sprung geht, ist es meiner Meinung nach unnötig andere Seiten außer der aktuellen mit pageActive zu aktivieren.
In dem Fall kann man das Scrollen recht einfach erreichen, wenn man das "Sichtfenster" (also #pages) vor dem scrollen direkt rechts oder links von der anzuzeigenden Seite positioniert und dann ganz normal das Scrollen startet.
Das hab ich mir mal testweise implementiert und es macht einen guten, intuitiven Eindruck.
Wenn es keine Einwände gibt, würde ich das so ins SVN laden.

Hat die pageActive-Klasse noch irgendeine andere Funktion? Oder wäre die dann überflüssig, wenn mans so wie beschrieben löst?

Gruß
Tobias