ResponsiveDesign - Materialize Admin

[mcm1957]

@simatec
FYI

[simatec]

@mcm1957 Ich bin da in dem Issue in Kontakt und hatte auch einen PR gemacht. Leider wurde das geschlossen.

[simatec]

@skb ab Admin v7.2.6 wird s12 automatisch gesetzt, da in vielen index_m die Class nicht berücksichtigt wird und in der mobilen Ansicht die Configs nicht bedienbar sind.
Für deinen Adapter hatte ich die Anpassungen gemacht, so dass es in allen Auflösungen gut bedienbar und lesbar ist.

Und ja in der mobilen Ansicht < 600px ist s12 gesetzt und der Button unterhalb des Inputs.

Wir können aber gerne nochmal gemeinsam schauen, ob es sinnvoll ist, den Input kleiner zu machen.
Meiner Meinung nach, kann man dann aber den State im Input nicht mehr richtig erkennen

[SKB]

@simatec Naja, es sieht so auf keinen Fall gut aus - wenn man mehrere Inputs untereinander hat und dann jedesmal der floating Button in die Zeile darunter rutscht. Da erkennt man nicht mehr, das dieser Button zu dem Input gehort.

Ich fände eine Klasse toll, wo man das Icon quasi mit im Input hätte oder das Input ansich in Verbindung mit einem Button kleiner wird.

Das Issue habe ich aus den o.g. Gründen geschlossen, weil ich es als nicht so sinnvoll empfinde.

[simatec]

@skb der PR hat die Darstellungsfehler in der mobilen Ansicht behoben und wurde von mir erstellt, weil du das Issue zum Responsive Design Check geschlossen hattest, ohne dass es eine angepasste Ansicht der mobilen Darstellung gab.

Für deinen speziellen Fall schaue ich mir gerne nochmal das Thema an und überlege mir mal etwas

[SKB]

@simatec Der PR hat das Problem mit dem Button bzw. Input Feld nicht behoben. Es sieht ja so aus, wie jetzt.

Das Issue ist ja wieder geöffnet, nachdem auch ich die Info erhalten habe, das mit der aktuellen Beta Admin Version zu testen ist (was leider nirgendwo erwähnt wird/würde).

Ich denke auch, das es nicht so ganz geschickt ist, einfach plump die Input Felder auf s12 zu ziehen (aufgrund der Thematik, das mutmaßlich mehrere Entwickler ein solches Input Feld haben, wo die Lupe dahinter ist).

Beim Denon Adapter sieht das nämlich auch doof aus, wenn die Lupe unterhalb des Feldes ist.

[SKB]

@simatec Ich habe mal ein wenig geschaut und bin zu folgendem Vorschlag gekommen.

Was hälst Du davon?

CSS:

@media screen and (max-width: 768px) {
	.adapter-body {
		overflow: auto;
	}

	/* Overwrite the s12 class from materialize.css */
	.m .row .col.s12.for-icon {
		width: 83.33333%;
	}

	/* Overwrite the s12 class from materialize.css */
	.m .row .col.s12.icon {
		width: 8.33333%;
	}
}

HTML:

<div class="row">
	<div class="input-field col m11 s10">
		<input class="value" id="label_production" type="text" />
		<label for="label_production" class="translate" data-lang="label">Label:</label>
		<span class="translate" data-lang="ex_label">label inside the element</span>
	</div>
	<!-- Feld bekommt for-icon -->
	<div class="input-field for-icon col m11 s10">
		<input class="value dp" id="production" type="text" />
		<label for="production" class="translate" data-lang="state_production">Production state:</label>
		<span class="translate" data-lang="ex_production">Data point of your photovoltaic
			production</span>
	</div>
	<!-- Icon bekommt icon -->
	<div class="input-field icon col m1 s1">
		<a class="btn-floating waves-effect waves-light blue input-field datasource"><i
				class="material-icons">search</i></a>
	</div>
</div>

Screenshot:

Könnte man ja so mit in die CSS aufnehmen?!

[simatec]

@skb Ich habe dir einen Fix erstellt, der das mit Javascript löst... Grundsätzlich finde ich aber die Ansicht auf dem Handy mit dem Input und Button in einer Zeile für nicht optimal bedienbar und lesbar

[SKB]

@simatec Verstehe nicht so ganz, wieso man mit einem Javascript alles abändert und dann wieder ein neues Javascript, welches wieder Dinge hinzufügt. Die Kunst der Sache liegt doch einfach darin, CSS so zu nutzen, das eben nicht alles mit Skripten hin und her gewechselt werden muss. Ich kenne so gut wie keine Responsive Designs, die Javascript nutzen (müssen).
Die Gefahr hier besteht ja auch wieder, wenn in der ioBroker-Schmiede Dinge entwickelt/verändert werden, das die Skripte nicht mehr richtig greifen oder ähnliches.

Der Fix sagt mir so nicht zu.

So stelle ich mir persönlich Responsive nicht vor!

Was genau ist für dich denn in meinem Screenshot nicht lesbar?

Du meinst also, ein auseinander gerupfter Button, der irgendwo unter dem Feld zu sehen ist, macht das Design ansprechend?

[simatec]

@skb Du kannst es auch sehr gerne mit CSS machen... Wollte nur behilflich sein

[SKB]

@simatec Das ist sehr löblich von Dir

Mein Anliegen war eher der Punkt, wieso fügt man nicht eine entsprechende Klasse, die ich ja oben bereits gepostet habe, in das Materialize mit in ein und stellt es den Entwicklern zur Verfügung, damit sie es auch nutzen können.

Wenn jeder nun das Skript nutzt, wird das um ein vielfaches mehr Code, als 6 Zeilen CSS passend zu nutzen, oder?

[simatec]

@skb sagte in ResponsiveDesign - Materialize Admin:

Die Kunst der Sache liegt doch einfach darin, CSS so zu nutzen, das eben nicht alles mit Skripten hin und her gewechselt werden muss. Ich kenne so gut wie keine Responsive Designs, die Javascript nutzen (müssen).

Das ist leider bei sehr vielen Materialize Adaptern nicht der Fall. Deshalb setzt der Admin automatisch die Class s12 in der mobilen Ansicht.
Wir wollen mehr Responsive und die meisten Entwickler kennen sich weder mit Frontend noch CSS aus und wissen nicht, was die Klassen sX mX und lX bedeuten.

Genau aus dem Grund greift hier der Admin und setzt die richtige Class für die entsprechende Auflösung.

Wenn du es mit CSS anders gestalten willst, dann kannst du das gerne machen.
Wichtig dabei, es sollte ins Gesamtbild von ioBroker passen, da wir mehr Einheitlich werden wollen und es sollten funktionell und lesbar sein. Und das auch auf einem Display mit 360px.

Ich möchte hier auch nicht weiter mit dir diskutieren. Hab heute 2 PR's für dich gemacht und Zeit investiert um dir zu helfen... Wenn du es nicht möchtest ok, aber ignoriere nicht die Dinge, die in dem Issue stehen und auch die Scrollbarkeit in der mobilen Ansicht, die bei deinem Adapter nicht funktioniert.

[SKB]

@simatec Für deine Hilfe bedanke ich mich!

Natürlich passe ich die Oberfläche scrollbar an - das kommt ja erst seit dem Admin 7.2.6 - wo mir die Information fehlte, das dieser zum Testen zu nutzen ist (stand leider nirgendwo).

Auch passe ich meine DP Felder mit der Lupe an, damit sie einheitlich aussehen. Auch wenn die Lupe unter dem Feld wäre, stünden bei den 360px Bildschirmen
"nur" 40px (11%) mehr zur Verfügung, um den Inhalt der Textbox anzuzeigen - diesen Verlust würde ich als marginal betrachten.

Ich wollte hier nur behilflich sein, das andere Entwickler eben genau dieses CSS auch zur Verfügung haben, um DP Felder weiterhin so zu haben, wie sie vorher waren.

Es kann auch jeder sein eigenes Süppchen kochen und mit Javascript die CSS Styles aushebeln, die zur Verfügung stehen könnten.