Erweiterung der Navbars

[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

[henfri]

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

[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

[JuMi2006]

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

[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

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

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