Externe Widgets: Layout der Kästchen auswählen und Akzentfarbe zuweisen

Funktionsanfrage
1

Titel: Widgets für externe Integrationen: Layout der Kacheln und Akzentfarbe festlegen

Hallo,

Ich entwickle die externe Integration Prix Carburants. Ein Benutzer hat mir zwei Anmerkungen zur Karte „Meine Tankstelle“ gemacht, die ich nicht auf der Integrationsseite beheben kann, da sie vom Anzeige der Widgets in Gladys abhängen.

1. Layout der Kacheln

Derzeit gehen die Kacheln (value / gauge) in eine neue Zeile, wenn der Platz fehlt (flex-wrap, Mindestbreite 96 px). Bei 3 Kacheln auf einer schmalen Karte erhält man 2 Kacheln in halber Breite und 1 Kachel in voller Breite darunter. Der Benutzer würde es klarer finden, 3 Kacheln gleicher Breite, übereinander, zu haben.

Gladys sendet die Bildschirmbreite nicht an die Integration, daher kann die Integration nicht wählen.

Vorschlag: ein optionales Feld im Widget-Inhalt, zum Beispiel tiles_layout:

  • auto: wie heute (Standard);
  • row: alle Kacheln in einer Zeile, gleiche Breite;
  • stack: eine Kachel pro Zeile, volle Breite.

Ein unbekannter Wert entspricht auto, daher ändert sich nichts für bestehende Integrationen.

2. Akzentfarbe pro Kachel

Die zulässigen Farben sind „Sinnfarben“: neutral, primary, success, warning, danger, info. Das ist gut, um „ok / Achtung / Fehler“ auszudrücken, aber man kann sie nicht verwenden, um eine Kachel auf einen Blick zu erkennen. Zum Beispiel möchte der Benutzer die Farben der Zapfsäulen wiederfinden. Und Orange (warning) wird bereits in meiner Karte verwendet, um eine Unterbrechung anzuzeigen: die Verwendung der gleichen Farben für beide würde die beiden Bedeutungen vermischen.

Vorschlag: ein optionales Feld accent auf den Kacheln, das als kleiner Farbbalken oder Punkt angezeigt wird, getrennt von color (das seine aktuelle Rolle bei der Wertanzeige beibehält). Zwei mögliche Optionen:

  • eine freie Farbe #RRGGBB, überprüft von Gladys;
  • oder, um mit den hellen und dunklen Themen konsistent zu bleiben, eine kleine Liste von benannten Farben: green, yellow, blue, orange, red, purple, gray.

Zum Schluss

Beide Ergänzungen sind optional und ändern nichts an den bestehenden Widgets. Ich kann einen Pull-Request vorschlagen, wenn Ihnen die Idee gefällt.

Danke!

2

Das Thema kommt genau richtig, ich hatte heute genau dieses Problem :+1:

3

Hallo @prohand,

Vielen Dank für dieses sehr gut dokumentierte Feedback (und danke @Lokkye für die Bestätigung)!

Beide Probleme sind real. Aber in beiden Fällen denke ich, dass die Lösung von Gladys kommen sollte, nicht von einem neuen Feld auf der Integrationsseite. Das ist das Grundprinzip der Integrations-Widgets: Die Integration beschreibt, was angezeigt werden soll, Gladys entscheidet, wie. Dadurch können wir sicherstellen, dass alle Widgets in hellen Themen, dunklen Themen, mit Horizon und bei allen Bildschirmbreiten konsistent bleiben.

1. Die Anordnung der Kästchen

Du hast einen echten Bug aufgedeckt, und dein eigenes Argument gibt den Schlüssel: Die Integration kennt die Bildschirmbreite nicht, sie ist also am schlechtesten positioniert, um die Anordnung zu wählen. Dasselbe Widget wird auf einem Telefon und auf einem Wandtablet angezeigt. row mit 6 Kästchen auf einem Telefon würde abgeschnittene Werte ergeben, und stack auf einer breiten Karte würde eine sehr hohe Karte ohne Grund ergeben. Eine feste Wahl wird irgendwo falsch sein.

Das Problem liegt in unserer Darstellung: Wenn der Platz fehlt, geht ein Kästchen in die nächste Zeile und dehnt sich über die gesamte Breite aus. Mit 3 Kästchen in einer schmalen Karte ergibt sich genau das „2 + 1“, das du beschreibst, und das betrifft alle Integrationen, nicht nur deine.

Wir werden das also direkt in Gladys korrigieren, ohne ein neues Feld: ein ausgewogenes Raster, das die Anzahl der Spalten basierend auf der Anzahl der Kästchen und der tatsächlichen Breite der Karte wählt und nie ein einzelnes Kästchen dehnt. Dein Widget wird davon profitieren, ohne dass du etwas ändern musst, genau wie alle anderen.

2. Die Akzentfarbe

Freie hexadezimale Farbe: nein. Das ist eine bewusste Entscheidung von Anfang an: Wir könnten den Kontrast im Dunklen Modus oder mit Horizon nicht mehr garantieren, und es wäre die Tür zu Markenfarben geöffnet.

Eine benannte Palette hingegen ist eine echte Frage. Du hast Recht, warning nicht zu missbrauchen: color drückt einen Zustand aus (ok / Achtung / Problem), während du eine Identität ausdrücken möchtest (welcher Kraftstoff). Und der Bedarf geht über Kraftstoffe hinaus: Mülltonnen (gelb, grün, blau…) sind typischerweise in derselben Situation.

Ich habe trotzdem zwei Bedenken:

  • Für den Benutzer bleibt eine Farbe eine Farbe: Ein roter oder oranger Balken wird als Warnung gelesen, egal wie der Feldname lautet. Die Verwirrung, die du vermeiden möchtest (orange = Ausfall), würde visuell wieder auftreten.
  • Das „Regenbogen“-Risiko: sechs Kästchen mit sechs Farben, das ist genau die Überlastung, die wir vermeiden wollen.

Wenn wir das tun, dann unter diesen Bedingungen:

  • eine geschlossene Liste von Farben, die Gladys selbst an das helle Thema, das dunkle Thema und Horizon anpasst (Kontrast eingeschlossen: ein Gelb auf weißem Hintergrund ist nicht so lesbar);
  • angezeigt nur als kleines Identitäts-Icon, nie als Farbe des Wertes oder des Hintergrunds (das bleibt die Aufgabe von color);
  • verfügbar überall, wo ein Icon etwas identifiziert: die Kästchen, aber auch die Zeilen von status (ein Müllsammel-Widget würde eher eine Liste verwenden);
  • einfach ignoriert von einer älteren Version von Gladys.

Da es sich um ein zweites Farbsystem handelt, das alle Widgets betrifft, möchte ich diesen Punkt lieber separat behandeln und ihn spezifizieren, bevor ich ihn codiere, anstatt ihn zusammen mit dem Anordnungs-Fix hinzuzufügen. Wenn andere Anwendungsfälle haben, zögern Sie nicht, diese hier zu teilen, das wird helfen, eine Entscheidung zu treffen :slightly_smiling_face:

In der Zwischenzeit reichen für Prix Carburants die Beschriftung und das Icon jedes Kästchens aus, um den Kraftstoff zu identifizieren, und du hast völlig Recht, warning für die Ausfälle zu behalten.

Nochmals vielen Dank für den Vorschlag und das Angebot eines PR! Für den Akzent warten wir, bis wir uns hier entschieden haben, bevor wir mit dem Code beginnen.

4

Ticket:

5

Danke, dass du das Thema prohand erstellt hast, hier werden die Tickets in Windeseile bearbeitet! (Zumindest schneller als bei der Arbeit, haha).

Elegante Lösung, dieses „ausgewogene“ Raster @pierre-gilles danke :slight_smile: