Mobile Site parallel zu Desktop Site?

[flip-flop]

{ NAV_TABLE_COLUMN } und { NAV_LIST_TOP }
Diese älteren Navigationen funktionieren z.B. in einer r246 immer noch problemlos, gerade getestet.

Wird denn die Seitenstruktur überhaupt noch ausgelesen?

Code: Select all

dumpVar($GLOBALS['content']["struct"]);

Irgendwelche Scripte die nicht richtig funktionieren?
Testweise die Ordner frontend_int und frontend_render umbenennen.

Knut

[Oliver Georgi]

Kopie nur wegen Mobile ist der falsche Weg!

Die r426 des CMS momentan meiden – hat einen unschönen Bug. r427 in Vorbereitung.

[pepe]

Was die Navigation angeht, da verwende ich einfach eine floatende NAV_LIST_UL-Variante... die sortiert sich schon selbständig hintereinander, bei Bedarf auch mehrzeilig.
Sieht in den kleinen Monitorgrößen momentan noch nicht perfekt aus, funktioniert aber ohne Probleme.

Bin ja erst seit Sonntag "am Spielen", Feinheiten kommen dann MORGEN

Bestehende Sites würde ich aber gar nicht versuchen, umzustellen, man muss sich schon einige Gedanken machen, wie man den Inhalt anordnet. 2 spaltige Layouts funktionieren relativ leicht, 3 spaltige werden bei 320px Breite zum Ratespiel.

Auch hier gilt wieder: Planung ist die halbe Miete... eher sogar 80% des Kuchens!

[pepe]

... es gibt da ein RT Problem mit der NAV_UL.
...
CSS-Auflösung ist auch alles da!siehe hier! - wie war das mit den Bäumen und dem Wald?
Woran könnte das nun wieder liegen?

Nicht dass es lediglich die Einstellungen in der Config sind, die den "Fehler" bewirken.
Man wird mit der Zeit blind für einfache Fehler

[kukki]

Richtig, pepe - und da hilft auch keine Brille mehr!
Geht mir auch mit der Rechtschreibung so, obwohl ich schon immer ein guter Schreiber war, geht wegen der Brille die Fehlerquote doch in die Höhe und man sieht es einfach nicht mehr.

Unschöner Bug in der Version 426 - nah gut warten wirs ab!

@pepe: Für die Spaltendarstellung solltest Du versuchsweise durchgängig CSS3 zu benutzen, da gibt es jetzt die Notation
column-count; ~-gap; ~-width; *-spam.
Die Dinger haben auch gwisse Schwächen, aber den Vorteil, dass Sie auf allen Endgeräten, die bereits CSS3 definitiv unterstüzen, auch wirklich laufen.

[kukki]

(1) Kopie nur wegen Mobile ist der falsche Weg!
(2) Die r426 des CMS momentan meiden – hat einen unschönen Bug. r427 in Vorbereitung.

zu (1): das habe ich aus
a) Bequemlichkeit gemacht und auch mit der
b) Idee im Hinterkopf eine Desktopseite für mobile Geräte umzustellen/ zu erweitern.
So dumm ist diese Vorgehensweise nicht, schließlich sollen damit alle Varianten bedient werden und nur noch - so meine Vorstellung - anhand einer CSS-Steuerung die Anzeigeräte angesteuert werden.

(2) welche Auswirkung hat dieser Bug?

[update]

column-count; ~-gap; ~-width; *-spam

~-spam, das ist gut

Oliver Georgi wrote:(1) Kopie nur wegen Mobile ist der falsche Weg!
.....

Der richtige(re) Weg wäre dann....?

[update]

double post

[pepe]

Ich denke, der richtige Weg wäre, alles in einer Anwendung unter zu bringen.

Man wird aber stark umdenken müssen, beim Aufbau einer Site, damit auch alles auf den 320px eines alten "Mobile" dargestellt werden kann.


Toll wäre natürlich ein CMS, welches diese "neue" Idee unterstützt und z.B. für die verschiedenen Größen an gängigen Ausgabegeräten die passenden Bilder "automatisch" generiert... und auch bei Bedarf verknüpft bzw. darstellt.
Aber ich träume mal wieder....

[kukki]

{ NAV_TABLE_COLUMN } und { NAV_LIST_TOP }
Diese älteren Navigationen funktionieren z.B. in einer r246 immer noch problemlos, gerade getestet.
.....
Knut

Habe gerade das { NAV_TABLE_COLUMN } in der originalen Version kurz mal reingestellt - und es funktioniert, aber halt in der kopierten Version nicht. Auch der Dump zeige gähnende Leere. Da ist wirklich der Wurm drin, ist aber die Datenbank 1:1 kopiert gewesen, keine Manipulationen!

Und

Code: Select all

 dumpVar($GLOBALS['content']["struct"]);

zeigt im Original eine feine Struktur an, in der kopierten Version aber nichts. Ist aber haargenau die gleiche Struktur. Und die Vergrößerung des Bildes funktioniert auch.

ABER: ich habe mal per Hand nach der Originalstruktur ~/kleine-helfer.phtml in die Browseradresszeile eingetragen. Er findet diese Angabe nicht! und zeigt die Fehlermeldung (404) aus der Vorlage an!

[kukki]

Die Vorgehensweise ist relativ einfach. Wir bauen unsere Seiten wie bisher zusammen und verlagern alle(!) CSS-Angaben in die frontend.css.
Dann entscheidet man, in welcher Reihenfolge die *.css2.1/ css3 zu laden sind (css3-mobile first oder desktop first) - dementsprechend entscheidet sich auch, wie bestimmte CSS-Notationen zu überschreiben sind. Die Desktop-Browser ignorieren sowieso eine Menge der CSS3-Formatierungen für mobile Geräte. (jedenfalls noch) Anhand der CSS media-queries werden die Viewprts abgefragt und dementsprechende Umformatierungen vorgenommen.

Mir ist aufgefallen, dass man sogar ohne CSS-Steuerung die Anzeigen in einem mobilen Endgerät hinbekommt, sieht zwar nicht schön aus, aber es ist ein Ansatz zum Überlegen, was hier zu tun wäre, zumal automatisch die (beschränkte) Anpassung an den aktuellenn Viewport vorgenommen wird.

[santscho]

Wenn man es "richtig" machen will, kommt man zur Zeit mit phpwcms um eine zweite Installation nicht herum. Die Anforderungen desktop/mobile sind einfach zu unterschiedlich. Und ein Template fuer die Desktop-Seite ist halt nun mal anders als das Template fuer die Mobile-Seite. Und auch die Art der Navigation ist auf Mobile total anders: Zum Beipiel horizontale Navigation mit dropdown... Diese nested <ul> muss irgendwie auf Mobile umgestellt werden. Schwierig. Und was ist mit Spalten? Warum auf Desktop alles in einer Spalte unterbringen wenn man doch 1000 pixel Breite zur Verfuegung hat, die man auch ausnutzen soll?

Und das sind nur Layout-Probleme die zu loesen sind.Jetzt kommen da noch die Content-Schwierigkeiten dazu. Viel Spass!

Nehmen wir zum Beispiel Bilder/Galerien: Diese muessen sich beim Orientierungswechsel des mobilen Geraetes auch wieder an Breiten anpassen, was aber auf der Desktop-Seite nicht erwuenscht ist. Und auf der mobilen Seite moechte ich gerne "pinch" und "swipe" fuer Bilder verwenden. Eine "Zweifinger-Maus" fuer den Desktop muss noch erfunden werden und dann hat sie vermutlich nicht jeder. Also brauch ich fuer Desktop ein Lightbox-Template und fuer Mobile ein "Pinch-Zoom" Template. Kann ich im CP zwei unterschiedliche Templates definieren? Denke nicht.

Beispiel Daten-Saetze: Vergleicht mal dies http://www.oneasiafest.com/workshops-and-seminars.phtml mit dem http://oneasiafest.com/guide/index.php? ... -schedules ... Gleicher Datensatz wird verwendet. Aber auf Desktop ein Tabellen-Template, auf Mobile ein "collapsible" jQuery Template, da die Tabelle auf einem iPhone einfach nicht zu lesen waere.

Beispiel Artikel-Teaser: Auf der Deskop Seite ist ein Icon-Teaser wie hier nicht zu gebrauchen: http://oneasiafest.com/guide/index.php?mobile-guide. Auf dem mobilen Geraet ideal.

Mein Fazit: Eine komplexe Webseite laesst sich nicht so einfach mit phpwcms fuer mobile/desktop coden. Ich finde meine Variante immer noch die einfachste und effizienteste.

[santscho]

z.B. für die verschiedenen Größen an gängigen Ausgabegeräten die passenden Bilder "automatisch" generiert... und auch bei Bedarf verknüpft bzw. darstellt.
Aber ich träume mal wieder....

Pepe, das laesst sich mit einfachem CSS bewerkstelligen. Guck mal hier http://oneasiafest.com/guide/index.php?category-animals und veraendere die Groesse des Browser-Fensters. Groessen der Bilder passen sich schoen an.

[Oliver Georgi]

Geht alles Ralph — verlangt nur etwas mehr Vorplanung. 2 Installationen sind nicht nötig. Das bringt mich aber auf die Idee, noch einen Pre-Parser für die Templates aufzuschalten. Dann könnte man eventuell sowas nutzen:

Code: Select all

<!--Device:iOS-->
iOS-related Template stuff
<!--/Device:iOS-->
<!--Device:Default-->
Default Template stuff
<!--/Device:Default-->

Alles andere dann per Scripting (JavaScript oder PHP)

[update]

Das bringt mich aber auf die Idee noch einen Pre-Parser für die Templates aufzuschalten.

HA! Goil Das wär' was