Responsive Layout

[Chris M.]

Hinter dem Buzz-Wort Responsive Design verbirgt sich ja nicht mehr, als dass je nach verfügbaren Platz Teile nicht oder unterschiedlich breit dargestellt werden - und das ganze "springend", d.h. bei s.g. Break Points findet ein Wechsel statt. (Bei einem fluiden Design nimmt der Inhalt immer den ganzen Platz ein und es gibt keinen fixen Wechsel).

Die CometVisu unterschtützt das ja schon seit langem - aber ich habe das Gefül, es ist nicht so optimal wie es sein könnte.

Aktuell wird von 12 Spalten ausgegangen, die bei Mobilen Geräten, oder wenn enable_column_adjustment="true" gesetzt ist, je nach min_column_width auf weniger Spalten reduziert wird.
=> Wird diese System aktuell von euch gut genutzt?

Ein alternativer Ansatz wäre neben den aktuellen colspan-Werten weitere (z.B. "colspan-s" und "colspan-m" genannt), die bei entsprechend kleinem Bildschirm zum Einsatz kommen. Basis wären dann immer 12 Spalten - aber per Config-Datei könnte man dann exakt angeben, ab wann man breiter werden will und wie breit. (Evtl. könnte man dann auch ein Wert von "0" setzen, der bei dieser Größe diesen Inhalt weg lässt)
=> Wäre das ein Fortschritt?
(Oder gar ein Rückschritt, da man pro <layout> im Zweifel auch noch zwei weitere Attribute befüllen müsste...?)

[alltime]

min_column_width kannte ich noch gar nicht...muss ich mal testen.

In meinem Layout haben alle Elemente/Blöcke die gleiche Breite und je nach Typ die gleiche Höhe oder eben Vielfache davon. Das sieht einfach besser aus als unterschiedlich große Widgets.
Bis jetzt habe ich mir mit zwei Page-Layouts geholfen. Für Smartphones habe ich immer nur ein Element/Block pro Zeile mit einem Colspan von 3.
Für größere Bildschirme haben die Blöcke einen Colspan von 4. Das ist für Tablets und normale Monitore geeignet. Bei größeren Monitoren wäre ein Colspan von 3 wieder ideal...
Das ist jetzt für meine Geräte optimal. Allerdings passt das Smartphone Layout schon wieder nicht für das iPhone 6 oder ähnlich große Monitore. Hier wäre wieder 4 ideal...

Kurz gesagt, ja, zwei weitere colspans wären super! Ich wollte mir eh schon eine weitere Einstufung wünschen.

Allerdings denke ich, dass man um zwei Layouts wohl nicht drum rum kommt um alles optimal anzuzeigen.
Mein Parser erzeugt im Moment immer zwei Layouts parallel und im Menü wird dann einfach das nicht passende Layout ausgeblendet.
Z.B. Gruppiere ich die Funktionstypen (Licht, Fenster, Heizung,...) in extra Tabs bei Mobilgeräten wenn die Anzahl an Funktionen (Licht 1, Fenster 1, Fenster 2, ...) größer als 5 ist und die Anzahl an Funktionstypen größer als 1 ist. Sonst scrollt man einfach zu viel.
Schön wäre es, wenn man die Elemente eines Funktionstyps in einen Kontainer packen könnte, der horizontal scrollbar wäre, ähnlich wie bei Google Play

[alltime]

Vielleicht würde es auch reichen wenn enable_column_adjustment immer in (z.B. 3er) Blöcken die Spalten verringert. Je nach Displaygröße konnte man dann 1-,2-,3- oder 4-spaltig Widgets anzeigen. Im Moment kann es passieren, dass nur ein Widgets (3 Spalten groß) angezeigt wird aber daneben noch eine leere Spalte steht, da das Display 4 Spalten fasst...

[Chris M.]

Ja, den aktuellen Spaltenreduzierungs-Algorithmus halte ich auch für unglücklich. Darum bin ich ja auch auf die Idee (die natürlich nicht von mir stammt) gekommen mit mehreren colspan-Werten zu arbeiten.

[ctr]

Also ich finde die derzeitige Layoutmöglichkeiten zwar in der Theorie gut, aber in der Praxis kaum umsetzbar. So habe ich für mehrere Endgeräte (mit unterschiedlichen Auflösungen) mehrere Configs. Besonders stört mich, dass die Größe der Zeilen dynamisch ist und das Umbruch-Verhalten bei zu viel Content pro Zelle. Wenn man da etwas ändern könnte, würde ich das sehr begrüßen.

[Chris M.]

ctr würde Dir so eine Möglichkeit helfen, in jedem Layout auch Colspan-Werte für kleine und mittlere Displays angeben zu können?

[ctr]

Ich denke Skalierung ist das Thema, auf jeden Fall für Schrift, evtl auch für Icons. Wenn das funktioniert, würde ich mir *feste* Werte für die Zellgrößen wünschen, die dann durchaus je nach Displaygröße unterschiedlich sein können. Ich attache mal später oder morgen ein paar Screenshots von einer verschachtelten Tabelle wo man das zugrunde liegende Probleme sehr gut sieht, evtl gibt es ja noch bessere Lösungsmöglichkeiten.

[Chris M.]

Im Pull-Request https://github.com/CometVisu/CometVisu/pull/256 habe ich nun mal ein neues colspan-Handling implementiert, wo man auch ein "colspan-m" und "colspan-s" vergeben kann, dass den Colspan-Wert für mittlere (m) und kleine (s) Bildschirme angibt. Basis sind immer 12 Spalten (bzw. in einer Group natürlich die Spalten-Anzahl der Group).

Wenn man die Werte nicht angibt, wird ein Default angenommen, der halbwegs sinnvoll skalieren sollte (und meiner Meinung nach sinnvoller ist, als die vorher automatisch sich veringernde Spaltenanzahl)

[Chris M.]

Da der Pull-Request jetzt gemerged wurde bitte ich um intensive Tests und Berichte über seltsames oder gar fehlerhaftes Verhalten!
(Configs die das neue Feature noch nicht nutzen sollte sich nicht wesentlich anders verhalten als vorher...)

[alltime]

Sehr gut, vielen Dank! Das werde ich bei Gelegenheit testen.
Gibt es eine Möglichkeit die entsprechenden "maxScreenWidth"s in der Config zu definieren?
Und warum lässt du colspan-s unter 599 beginnen und nicht bei 480 (bei der mobile.css geladen wird)?

[Chris M.]

Gibt es eine Möglichkeit die entsprechenden "maxScreenWidth"s in der Config zu definieren?

Noch nicht. Würde aber sicher Sinn machen. Ggf. auch noch per URL übersteuerbar.

Und warum lässt du colspan-s unter 599 beginnen und nicht bei 480 (bei der mobile.css geladen wird)?

Ich hatte mich nach https://www.google.com/design/spec/l...ui-breakpoints gerichtet. Danach ist die magische Schwelle wohl irgendwo zwischen 480 und 599.
480 war beim Desktop-Browser zum testen zu klein und die 599 hatten gut funktioniert

Letztendlich müssen wir uns auf die passenden Wert hin iterieren - und dass natürlich vor der 0.9.1

[XueSheng]

(Configs die das neue Feature noch nicht nutzen sollte sich nicht wesentlich anders verhalten als vorher...)

Hatte bislang das enable_column_adjustment="true" verwendet. Dies scheint es ja nun nicht mehr zu geben. Auf Mobilgeräten wurden bislang immer 3 columns angezeigt (hierauf habe ich auch meine Visu ausgelegt). Nun sind es 4 columns. Der colspan/rowspan test in der Visu sieht nun auch deutlich anders aus (Screenshots angefügt).

Wie kann ich auf Mobilgeräten wieder 3 columns erzwingen?

colspan_old.png colspan_new.png

[Chris M.]

Hatte bislang das enable_column_adjustment="true" verwendet. Dies scheint es ja nun nicht mehr zu geben. Auf Mobilgeräten wurden bislang immer 3 columns angezeigt (hierauf habe ich auch meine Visu ausgelegt). Nun sind es 4 columns. Der colspan/rowspan test in der Visu sieht nun auch deutlich anders aus (Screenshots angefügt).

Ok, da die bisherige Anzahl relativ "zufällig" war befürchte ich, werden wir hier keine gute Lösung finden das automatisch besser hin zu bekommen. (Zufällig, da ein anderes, ähnliches Gerät mit bisschen abweichender Auflösung schon eine andere Spalten-Anzahl haben konnte. Mit anderen Worten: bei jedem Handy-Wechsel war es möglich, dass die Spalten-Anzahl anders wurde)

Wie kann ich auf Mobilgeräten wieder 3 columns erzwingen?

Das sollte relativ einfach - und v.a. reproduzierbar - gehen:
Gib den Layout-Elementen ein "colspan-s" bzw. "colspan-m" mit der Anzahl an Spalten die dieses Widget bei kleinen bzw. mittleren Bildschirmen haben sollte. Ein colspan von 4 wäre für ein 3-spaltiges Layout die richtige Wahl.