Erweiterung der Navbars

[peuter]

Das SVN ist zum Arbeiten da. D.h. wenn man Feedback will, kann man gerne einchecken, so das andere es probieren können. Und wenn's nicht passt nimmt man's einfach wieder zurück - dazu ist's ein Versionskontrollsystem
(Der "Qualitätsanspruch" an dem Stand im SVN ist, dass es immer "funktioniert", d.h. das die Widget-Demo bei den üblichen Designs ohne offensichtliche Mängel funktioniert. Das sollte man vor dem Einchecken testen. Größere Umbauarbeiten die das nicht gewährleisten einfach vorher hier absprechen, dann gehen die auch i.O.)

Ok, habs eingecheckt. Ich war an dieser Stelle nur etwas vorsichtiger, da ich bei dieser ganzen Seitenwechsel-Geschichte nun schon öfter gedacht hab ich hätte es jetzt kapiert, um dann doch wieder festzustellen, dass dem nicht so ist. Momentan bin ich wieder an einer Stelle, wo ich denke ich habs kapiert . Mal sehen obs so bleibt.
Getestet hab ich meinen Fix mit der demo/metal config und keine Probleme festgestellt.

[Chris M.]

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.

Das SVN ist zum Arbeiten da. D.h. wenn man Feedback will, kann man gerne einchecken, so das andere es probieren können. Und wenn's nicht passt nimmt man's einfach wieder zurück - dazu ist's ein Versionskontrollsystem
(Der "Qualitätsanspruch" an dem Stand im SVN ist, dass es immer "funktioniert", d.h. das die Widget-Demo bei den üblichen Designs ohne offensichtliche Mängel funktioniert. Das sollte man vor dem Einchecken testen. Größere Umbauarbeiten die das nicht gewährleisten einfach vorher hier absprechen, dann gehen die auch i.O.)

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

Die erste wichtige Funktion ist die, dass nicht mehr interaktiv das sytle-Attribut angefasst werden muss. Hier musste ich lernen, dass das zwar schnell geht und erst mal schön offensichtlich ist. Aber wenn z.B. ein Design aus bestimmten Gründen das doch anders lösen möchte (und sei es nur eine DOM-Abfrage) wird's kompliziert.
=> Die Logik sollte nur Klassen setzen und löschen.

Ansonsten hat ein grep über die ganzen Sourcen keine offensichtliche Nebenwirkung gezeigt.

Zum scrollen hab ich mal ne Frage bzgl der Endgeräte. Bis vor kurzen war der Stand mit dem iPad dass das Scrollen einfach jämmerlich aussah. Mit der letzten SVN Version wird nun nicht mehr gescrollt (zumindest in meiner config) und das Einblenden der Seiten sieht einfach freundlich aus.

Braucht das einblenden und ausblenden besondere Rechenleistungen?

Grundsätzlich sind die Mobil-Prozessoren erstaunlich leistungsfähig (vergleicht mal wie lange es her war, dass so eine Rechenleistung erst im PC verfügbsr geworden ist!).
Aber: Web-Seiten darstellen, besonders das auch noch flüssig, bringt die nicht nur an die Grenzen, sonder drüber hinaus. Das merkt man aber normaler weise nicht, da die mobilen Browser das ganz geschickt verbergen können, in dem die die integrierte Grafik-Beschleunigung nutzen.

In der Praxis kann man das ganz leicht ausprobieren:

• In den Text Zoomen - geht ganz weich, wird aber erst mal grisselig, da nur die GPU das "Bild" vergrößert. Wenn dann mit der Geste aufhört wird schnell ein neu gezeichnetes Bild drüber gelegt.
• Schnelles Scrollen aus den aktuellen Sichtbereich heraus:
  Hier werden Grau-Weiße Kacheln angezeigt, bis dieser Teil auch gerendert wurde.

=> Ob es flüssig ist liegt nicht an der verwendeten CPU sondern an der GPU.


Nun gibt es Seiten die es der GPU schwierig machen und es muss auf langsames Software-Rendering umgestellt werden (ein paar von den "position" Möglichkeiten fallen da IIRC drunter).
Hier kann man dann probieren das geschickter im CSS abzubilden und den Geräten entgegen kommen.


Bisher habe ich da noch keine Optimierung gemacht, da ich zum einen erst seit kurzem entsprechende Geräte habe und zum anderen erst von diesen Spezialitäten erfahren habe...

[makki]

Ah, das ist am Anfang schwer verdaulich, geht aber schon
Ich halte das scrollen eh für optionale Zeitverschwendung; sieht ja hübsch aus, braucht die Welt aber nicht bei der täglichen Visu-Bedienung, da soll die Seite IMHO AFAP da sein

Makki

[JuMi2006]

OT: Was ihr da zusammenkritzelt versteht ja kein Mensch mehr Das Ganze js ist für mich einfach nur kryptisch.

[peuter]

Zum scrollen hab ich mal ne Frage bzgl der Endgeräte. Bis vor kurzen war der Stand mit dem iPad dass das Scrollen einfach jämmerlich aussah. Mit der letzten SVN Version wird nun nicht mehr gescrollt (zumindest in meiner config) und das Einblenden der Seiten sieht einfach freundlich aus.

Ich dachte, das Problem hätte nur ich mit meinem Billig-China-Tablet. Das ist mit dem Seitenwechsel nämlich auch ziemlich überfordert. Eventuell sollte man, das per config abschaltbar machen.
Workaround für die design_setup.js:

if (/(iphone|ipod|ipad)/i.test(navigator.userAgent.toLowerCase())) {
  // disable scrolling
  main_scroll.getConf().speed=0;
  $('body').css('padding-top','1em');
  handleResize(true);
}

Das sollte auch den Abstand oben wieder herstellen.


Gruß
Tobias

[henfri]

auf nem ganz billigen android tablet ruckelt es nicht. Gleich Konfig auf Ipad ruckelt...

[JuMi2006]

Zum scrollen hab ich mal ne Frage bzgl der Endgeräte. Bis vor kurzen war der Stand mit dem iPad dass das Scrollen einfach jämmerlich aussah. Mit der letzten SVN Version wird nun nicht mehr gescrollt (zumindest in meiner config) und das Einblenden der Seiten sieht einfach freundlich aus.

Braucht das einblenden und ausblenden besondere Rechenleistungen? Über kurz, eher lang , soll irgendwann mal eine Visu an die Wand. Das muss dann was günstiges und robustes sein - sollte also mit wenig CPU noch die Comet darstellen können.

Der Abstand für iDingbumens oben ist seit der letzten SVN leider auch broken.

Gruß Mirko

[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

[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.

[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]

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.]

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]

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.

[mclb]

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

[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.