Lassen Sie uns über Gladys V4 sprechen

Genau, wenn ich entscheide, dass die Box nach rechts verschoben werden muss, will ich nicht, dass sie sich ohne meine Zustimmung bewegt :smiley:
Drag-and-Drop ist für mich ein Plus, aber wenn man sie einfach mit Pfeilen neu positionieren kann, ist das schon viel besser als in V3 :wink:

Alles klar, du hast gut gearbeitet :grin:

Hallo zusammen!

Heute arbeite ich immer noch an den Boxen des Startbildschirms und habe mich insbesondere mit der Erstellung einer „perfekten“ Box beschäftigt.

Das Ziel ist es, Richtlinien in der Dokumentation zu schreiben :slight_smile:

Ich habe die Box „Benutzerpräsenz“ genommen, die anzeigt, wer zu Hause ist und wer abwesend ist.

Die Box sieht so aus:

Hier ist der Inhalt, den ich in die Richtlinien aufnehmen werde.

Fehlerbehandlung

Die Box muss Fehler behandeln und eine entsprechende Fehlermeldung anzeigen:

  • In natürlicher Sprache (kein JavaScript-Dump)
  • In der Sprache des Benutzers (über die native Internationalisierung von Gladys 4)
  • Die Fehlermeldung muss detailliert sein, für jeden möglichen Fehlertyp (Netzwerkfehler, Gerät nicht verfügbar, usw.)
  • Der Fehler muss dem Benutzer anzeigen, wie er das Problem beheben kann: Die Anleitung muss klar sein und den Benutzer nicht zu den Protokollen oder technischen Manipulationen führen. Wenn der Fehler nur vorübergehend ist und keine Maßnahmen erforderlich sind, geben Sie dies an.
  • Der Fehler muss im Rahmen der Box angezeigt werden und nicht außerhalb, damit der Benutzer den Kontext des Fehlers versteht.

Beispiel:

Ladezeiten verwalten

Der Benutzer muss wissen, wenn etwas im Hintergrund passiert. Wenn Sie eine Anfrage starten, müssen Sie dies in der Benutzeroberfläche mit dem Standard-Loader von Gladys 4 anzeigen.

  • Der Loader muss in der Box sein
  • Achten Sie darauf, dass die Box eine Mindestgröße hat, damit der Loader nicht oben in der Box komprimiert wird.
  • Denken Sie daran, den Loader zu entfernen, wenn die Anfrage fehlschlägt. Der Loader ersetzt nicht die Fehlermeldung.

Beispiel:

01

Live-Verwaltung

Eine Box sollte nicht nur Daten anzeigen, sondern sicherstellen, dass sie während ihres gesamten Lebenszyklus aktuell bleibt.

Das Gladys-Dashboard hat das Ziel, einen langen Lebenszyklus zu haben, daher werden einige Boxen mehrere Tage/Wochen/Monate angezeigt, wenn der Benutzer das Tab in Vollbild auf einem Wandtablet lässt.

Jede Box muss Web-Sockets verwenden oder sich zumindest periodisch aktualisieren, um aktuell zu bleiben.

Beispiel für eine Live-Aktualisierung:

19

Größe der Box

Ihre Box zeigt eine Reihe von Daten an, die wahrscheinlich dynamisch sind. Achten Sie auf die Mindest- und Maximallängen der Daten.

Wenn Sie eine Liste anzeigen, achten Sie darauf, der Box eine maximale Größe zu geben und dem Browser eine Scroll-Leiste hinzuzufügen, wenn die Liste zu lang ist. Dadurch wird verhindert, dass Ihre Box riesig wird, wenn der Benutzer eine große Installation hat.

Wenn Ihre Box systematisch zu lang ist, denken Sie darüber nach, das Konzept Ihrer Box zu ändern, und ermöglichen Sie dem Benutzer beispielsweise, in der Box-Konfiguration einen Unterbereich der Daten auszuwählen.

Beispiel für eine Scroll-Leiste:

Leere Zustände

Wenn Ihre Box leer sein kann, denken Sie daran, einen speziellen Zustand zu erstellen, der angibt, wie die Box gefüllt werden kann.

Beispiel:

Das sind die Richtlinien, die ich in der Entwicklerdokumentation veröffentlichen möchte :slight_smile:

Letztlich gelten diese Richtlinien für das gesamte Gladys, aber die Boxen sind ein gutes Beispiel.

Zögern Sie nicht, wenn Sie Mängel an diesen Richtlinien finden!

Tatsächlich geht es darum, die Ausführung einer Szene zu verhindern oder nicht, wenn ein Gerät nicht mehr vorhanden oder nicht verfügbar ist. Wenn es notwendig ist: Fehler, wenn es optional ist: Warnung.

Beide Arten von Dashboards erscheinen mir eine gute Idee!

Ich denke, der Benutzer wird sich weniger verloren fühlen, wenn er die Kontrolle über beide Koordinaten hat. Für mich ist es sicherer zu sagen, dass die Box links und unter der Box X ist, anstatt nur nach einer anderen Box.

Für den Lebenszyklus der Boxen bin ich zu 100% dabei! :+1:

Einige Ergänzungen zu den Richtlinien:

  • Ladeanimationen direkt beim Start der Box einfügen, um leere Boxen beim Laden der Seite zu vermeiden
  • Ladeanimationen für Unterabschnitte der Box können interessant sein. (Beispiel: Die Überprüfung der anwesenden Benutzer kann zu unterschiedlichen Zeiten erfolgen und/oder für einen Benutzer länger dauern als für die anderen)
  • Eine Farbkodierung und Symbole für Informationen/Warnungen/Fehler verwenden, das hilft visuell zu erkennen, was passiert.
  • Nur die wesentlichen Informationen in die Boxen setzen, wenn es viele Dinge gibt, die man einfügen muss (z.B. Lampenverwaltung), den gesamten verfügbaren Platz in Form eines Gitters statt einer Liste nutzen

Diese wenigen Punkte mögen offensichtlich oder simpel erscheinen, aber sie helfen, die UX und UI zu verbessern :wink:

EDIT Neugier: Wird es möglich sein, Boxen zu haben, die zwei oder drei Spalten einnehmen, für Boxen, die viel Platz benötigen, wie der Kalender?

Super Arbeit :clap::clap:

Es ist verrückt, wie sich die Dokumentation für Entwickler in etwa einem Jahr verbessert hat! Sie ist sogar zu einem der wichtigsten Punkte geworden, um die du (und andere) dich kümmerst, und das ist auch gut so, denn es ist das Wichtigste, um Gladys zu bereichern.

Ich würde hinzufügen, dass auch ein Timeout erforderlich ist.
Als Benutzer mag ich es nicht, einen Loader 10 Minuten lang ohne Informationen im Kreis drehen zu sehen. Ich bevorzuge es, wenn nach einigen Sekunden oder einer Minute eine Fehlermeldung angezeigt wird.

@pierre-gilles
Ich dachte an etwas, als ich mein Szenario auf Android erstellt habe. Wäre es schwierig, „grafische“ Szenarien wie Automaten auf Android zu haben?

Also, ich habe viele Ideen, aber leider nicht das Wissen :hot_face:

@pierre-gilles ich habe das Gefühl, dass es nicht mehr möglich ist, ein Konto zu erstellen. Man wird direkt zur Anmeldeseite weitergeleitet, aber mein Docker-Image ist brandneu.
Irgendeine Idee?

Verstehe, aber wie ich schon sagte, ich glaube nicht, dass es am Benutzer liegt, das zu entscheiden. Wir entwickeln ein System, das funktioniert, das ist alles.

Das ist derzeit nicht möglich, aber deine Idee ist interessant. Derzeit habe ich ein System mit 3 klar getrennten Spalten erstellt. Fest in der Breite und unendlich in der Höhe:

Wenn man sich das Template ansieht, das ich verwende, haben sie ein anderes Raster.

Sie haben nur 2 Hauptspalten, und darin schneiden sie:

Es wäre möglich, das zu tun, aber meiner Meinung nach ist dieses Dashboard in der Realität viel weniger schön als im Mockup :stuck_out_tongue: Ich erkläre:

Um deine Spalte in 3 zu teilen, wie sie es tun, müssen 3 ähnliche Boxen platziert werden. Angenommen 3 Temperatur-Boxen. Gleiches gilt für die Teilung in 2.

Und wenn du nur „breite“ Boxen hast, dann wird dein Bildschirm nur in zwei Teile geteilt.

Was wir tun könnten, ist dem Benutzer eine gewisse Freiheit geben, 1, 2, 3, 4 Spalten zu haben, und dann innerhalb jeder Spalte neu zu schneiden. Dennoch bleibt es eine recht große Entwicklung, einen „rekursiven Dashboard-Builder“ zu erstellen.

Ich behalte die Idee im Kopf und werde sie mir ansehen, aber ich bin mir nicht sicher, ob es ein Projekt für die Alpha-Version ist.

Danke!

Tatsächlich sollte das spezifiziert werden.

Hallo! Ich habe darüber schon mehrmals gesprochen und persönlich bin ich kein Fan dieser Art von Editoren, ich finde, das ist nicht sehr publikumsnah.

Ich finde, das ist ein sehr „programmierter“ Ansatz, der uns sehr anspricht, aber nicht so sehr Nicht-Programmierer. Und vor allem wird es schnell unübersichtlich.

Ah, ich habe tatsächlich kürzlich etwas daran geändert, ich werde es mir ansehen.

Was ich hinzugefügt habe, ist die übliche Sicherheit: Es ist nur möglich, ein Konto zu erstellen, wenn die User-Tabelle in der Datenbank leer ist. Wenn bereits ein Benutzer vorhanden ist, kann man sich nur anmelden.

Für alle, die es interessiert, lade ich euch zu einem Entwickler-Anruf morgen, Samstag, den 18. Mai, um 9 Uhr französischer Zeit ein, um euch zu zeigen, wie ihr eine Entwicklungsumgebung für Gladys 4 einrichtet! :slight_smile:

Es findet hier statt:

cf @NilkOne

Kein Problem und dein Standpunkt ist nicht falsch :slight_smile:

Falls Sie sich fragen, wie Sie eine Gladys 4-Entwicklungsumgebung einrichten, ist die Aufzeichnung des Anrufs online!

Damit es für neue Mitglieder klar ist, habe ich alle offenen Issues im Gladys 3-Repo geschlossen und stattdessen ein Issue erstellt:

Damit können wir alle, die helfen möchten, zum Gladys 4-Repo umleiten :slight_smile:

Natürlich wird das „gladys-4-playground“-Repo beim Deployment von Gladys 4 in das Haupt-Gladys-Repo gemerged.

Hallo @pierre-gilles,
Tolle Arbeit für die V4 :+1:

Als ich mir die laufenden PRs angesehen habe, ist mir aufgefallen, dass viele Codeänderungen auf die Formatierung der Dateien zurückzuführen sind (Beispiel unten):

Könnte man nicht einen Linter oder eine IDE-Konfiguration hinzufügen, um das zu vermeiden?

Übrigens, bei der Arbeit verwenden wir in meinem aktuellen Projekt Husky, das es ermöglicht, den Code vor jedem ‹ git push › zu überprüfen. Kurz gesagt, es führt die Tests und den Linter bei jedem ‹ git push › aus, damit nichts kaputt geht :wink:

Hallo @pierre-gilles, super Arbeit! :+1:

Was die Seite der Dienste „Integrationen“ betrifft, schließe ich mich der Meinung von @Tlse-vins und @peb an:

  • eine Kategorie „Meine aktiven / konfigurierten Dienste“ hinzufügen
  • und eine Kategorie „Alle Dienste (verfügbar)“
    Ich finde, das wäre für den Nutzer klarer.

@pierre-gilles, zu deiner Frage zum Dashboard:
je bin für den Bearbeitungsmodus mit den Positionierungspfeilen, den du im GIF zeigst, ich finde das super :smile:
und dann idealerweise später Drag & Drop.

Gibt es ein Dokument mit einer Roadmap, das alle Entwicklungen / geplanten Verbesserungen auflistet? (von dir und den Anfragen der Community) sowie die Details der geplanten und die Abstimmungen?
o nutzt man nur die GitHub Issues?

Das ist bereits der Fall, und ich kann dir versichern, dass ich in dieser Hinsicht eher extrem bin :smiley:

Du hast eine Datei .eslintrc.json für den server und den front.

Hier handelt es sich um eine .json-Datei, tatsächlich fehlt hier wahrscheinlich eine Angabe für diese Art von Dateien, ich werde das überprüfen.

Ich bin kein Fan von Pre-commit/Pre-push-Hooks, das fördert keinen häufigen Commit/Push-Rhythmus (wenn du 7 Minuten warten musst, um zu pushen, tust du es seltener). Das ist eine recht umstrittene Praxis.

Für mich, da jeder Push zwangsläufig auf einem PR ist, muss es auf der CI-Seite knallen und anzeigen, dass der Code-Stil nicht in Ordnung ist. Danach liegt es im Ermessen des Entwicklers, die Tests lokal vor dem Pushen auszuführen, wenn er es nicht tut, dann ist das sein Pech, er wird auf der CI sehen, dass es Linting-Fehler gibt, und er muss sie korrigieren, damit sein PR gemerged werden kann :slight_smile:

Ich bin einverstanden, wir müssen einen Weg finden, dies in der UI anzuzeigen… im Moment habe ich keine Idee.
Falls jemand eine Idee hat, bin ich offen dafür.

Ja! Auf GitHub gibt es 70 Issues, jedes Issue ist ein Feature, das entwickelt werden muss.

Die Roadmap findest du weiter oben in diesem Thema, aber sie ist auch in GitHub mit 6 Meilensteinen eingetragen, die jeweils mit einem Release-Datum erstellt wurden:

@Pti_Nico: Nachdem ich mich informiert habe, ist das Linting von .json-Dateien nicht so einfach. Ich habe eine ESLint-Regel hinzugefügt, um sicherzustellen, dass die JSON-Dateien korrekt formatiert sind. Für die Validierung der Einrückung habe ich jedoch nichts gefunden. Wenn du eine ESLint-Bibliothek/Erweiterung im Kopf hast, bin ich dankbar.

Eine Lösung könnte sein, diese Dateien in .js umzuwandeln, aber ich bin wirklich kein Fan dieser Lösung (weil sie dann als „Codezeile“ zählt, obwohl es sich um Konfigurationen handelt). Und vor allem bei Übersetzungsdateien hindert uns das daran, automatische Tools wie POeditor zu nutzen, die JSON verarbeiten.

[Edit]: Ich habe bereits Prettier verwendet, aber es wurde nicht erzwungen. In Bezug auf den Stil ist es strenger als meine aktuelle Konfiguration, daher habe ich Prettier auf dem Backend und Frontend eingerichtet. Normalerweise sollten wir keine Probleme mehr haben.

Normalerweise, wenn du das Formatieren beim Speichern in VSCode konfigurierst, wird dein Code mit Prettier sauber sein und die CI durchlaufen. :slight_smile:

Hallo zusammen!

Heute Morgen habe ich über den CI-/Build-Prozess von Gladys 4 nachgedacht. Das Ziel ist es, einen 100% automatisierten und vor allem leistungsfähigen Prozess zu haben.

Ich würde gerne sehen, ob wir CircleCI anstelle von TravisCI für das CI verwenden könnten. Da ich es in anderen Projekten verwendet habe, ist es wirklich schneller als Travis.

Hier sind die Schritte des Build-Prozesses, die ich im Kopf habe:

Erklärung:

  • Dieses Schema ist ein « Workflow » von CircleCI.
  • Jeder Block ist ein « Build » von CircleCI.
  • Die Pfeile zeigen Abhängigkeiten zwischen den Builds an. Die vertikalen Builds werden parallel ausgeführt, und um zur nächsten Gruppe von Blöcken überzugehen, müssen alle vorherigen Builds ausgeführt worden sein. Beispiel: Hier wird « Netlify Webhook » erst ausgeführt, wenn die 4 Docker-Builds abgeschlossen sind.

@VonOx Das sollte dich interessieren! Wenn du Zeit hast, um das gemeinsam zu besprechen, wäre ich dabei :slight_smile:

Ich habe ein GitHub-Issue erstellt, um die Entwicklung zu verknüpfen:

https://github.com/GladysAssistant/gladys-4-playground/issues/120

Denn das Gateway-Frontend wird dasselbe Frontend wie Gladys in Gladys 4 sein :wink: In Gladys 4 wird es möglich sein, auf gateway.gladysassistant.com zu gehen und eine exakte Kopie dessen zu sehen, was du lokal auf Gladys siehst! (aber außerhalb deines Netzwerks, indem du über das Gateway mit Ende-zu-Ende-Verschlüsselung gehst)

Das ist nur ein Name in diesem Schema ^^ Für mich ist es dasselbe, wenn man releast, releast man alles: vom Code bis zur Dokumentation.

Wenn du willst :smile: Ich kann die Namen oben entfernen, wenn es dich stört ^^ es ist rein indikativ in diesem Schema.

Das Taggen muss vom Entwickler durchgeführt werden, nicht vom Continuous Integration. Es ist der Entwickler, der entscheidet, eine neue Version von Gladys zu veröffentlichen! Übrigens, wenn du den Block Nr. 3 zwischen « Testing » und « Building » betrachtest, geht der CI nur zu « Building », wenn es sich um einen getaggten Build handelt, nicht um einen normalen Push auf einen Branch (in diesem Fall werden nur die Tests ausgeführt).

:blush: Ja, gerne.

Hallo zusammen,

ich weiß, dass Gladys unter Windows, Linux, Raspberry installiert werden kann;
Aber kann Gladys V4 auch unter Respeaker V2 installiert werden?