Ich mag diese Idee sehr. Es ist das „logischste“ in meiner Situation, in der ich Grafiken nutze, um meinen Stromverbrauch zu verfolgen. Dadurch könnte man leicht von einem Tag zum vorherigen/nächsten wechseln (insbesondere auf dem Handy).
Ich habe keine Stimme mehr, aber ich unterstütze!
Sauber! Vollkommen 
Aber das Design muss noch überarbeitet werden ^^
Ich mag, was HelloWatt macht:
Aber wir haben nicht genau denselben Anwendungsfall, also muss es angepasst werden, aber so könnte es funktionieren
Schnelle Mockup:
Wobei, wenn der Benutzer auf den linken Pfeil drückt, muss « Letzte 24 Stunden » in « 15/01 08:43 - 16/01 8:43 » geändert werden, denke ich
@pierre-gilles Ich habe ab morgen etwas Zeit und möchte diese Funktionsanfrage erkunden, um den Bedarf zu präzisieren. Ich habe zwei Fragen, bevor ich beginne:
Toll 
Man muss an alle Interaktionen denken Beispiel: Auf meinem schnellen Mockup wird „letzte 24 Stunden“ angezeigt. Und wie mache ich, wenn ich auf „letzten Monat“ wechseln will?
Tatsächlich darf es keinen Zweifel geben, der einzige Unterschied zwischen dem Mockup und der finalen Entwicklung ist, dass die finale Entwicklung in Gladys ist
Man muss die ApexChart-Dokumentation erkunden und nur mögliche Vorschläge machen
Hallo!
Ich habe über diese Anforderung zur Weiterentwicklung nachgedacht. Ich mache einen grafischen Vorschlag unten, um zu zeigen, wie die neuen Elemente zur Zeitnavigation platziert werden. Und ich füge vor allem in einer zweiten Nachricht eine Liste von Regeln bei, die implementiert werden müssen, damit die Navigation so logisch wie möglich ist.
Die neuen Funktionen:
Das Kontrollkästchen ist ein Vorschlag, weil ich denke, dass die Navigation, beispielsweise im Zeitraum „7 Tage“, zwei mögliche Funktionen haben sollte:
=> Ich schlage also die Möglichkeit vor, zwischen den beiden Modi zu wechseln.
Anmerkung 1: Die Elemente werden alle über dem Diagramm platziert, daher denke ich, dass dies unabhängig davon ist, was Apexcharts kann oder nicht…
Anmerkung 2: Für die Rückkehr zu „Jetzt“ und für den Wechsel zwischen „regelmäßig/gleitend“ habe ich keine visuelle Wahl getroffen: Schaltfläche, anklickbarer Text, Symbol, Kontrollkästchen, Dropdown-Liste,… Ich denke, der Entwickler wird die richtige Wahl in Abhängigkeit vom verfügbaren Platz treffen…
Visuell könnte es so aussehen:
Die Regeln (fett gedruckt unten) sind, glaube ich, nicht so zahlreich, dass der zu implementierende Code eine „Rauchmaschine“ wäre. Aber ich gebe viele Erläuterungen und Beispiele, damit sich jeder ein Bild machen und Verhaltensweisen erkennen kann, die nicht relevant wären. Ich bin offen für euer Feedback, um es zu verfeinern!
====== Navigation mit den Pfeilen: ======
Hinweis: Zwei aufeinanderfolgende Aktionen, zuerst linker Pfeil, dann rechter Pfeil (oder umgekehrt), sind ‹ symmetrisch ›; dies bringt die x-Achse genau auf denselben Zeitraum zurück
Besonderer Fall: Wenn das Enddatum >= jetzt ist, wird der rechte Navigationspfeil deaktiviert (um nicht in die Zukunft zu navigieren, die noch keine Daten hat)
====== Wechsel des Modus ‹ regelmäßig/gleitend ›: ======
Im regelmäßigen Modus sind die Zeiträume wie folgt definiert:
Wenn man in den Modus ‹ regelmäßig › wechselt: Der neue Zeitraum enthält das vorherige Enddatum (man verschiebt sich also etwas in die Zukunft)
Wenn man in den Modus ‹ gleitend › wechselt: Der neue Zeitraum « passt sich » an den aktuellen Tag und die aktuelle Uhrzeit an (man verschiebt sich also etwas in die Vergangenheit)
Hinweis: Das neue Enddatum wird so spät wie möglich sein, ohne das vorherige Enddatum zu überschreiten
Hinweis: Die Ausrichtung auf den aktuellen Tag und die aktuelle Uhrzeit ermöglicht es, auf ‹ jetzt › zurückzukehren, wenn man mit dem rechten Pfeil navigiert…
Die Ausrichtung des Periodenendes erfolgt wie folgt, je nach Periodentyp (unter der Annahme, dass das aktuelle Datum Donnerstag, der 3. April, 18:25 Uhr ist):
Beispiele:
====== Änderung des Periodentyps: ======
Wenn man die Periode ändert, um sie zu verlängern:
Hinweis: Die neue, längere Periode enthält in der Regel die vorherige Periode vollständig, außer manchmal, wenn man von einer Periode ‹ 7 Tage › ausgeht
Wenn man die Periode ändert, um sie zu verkürzen:
Besonderer Fall: Wenn diese Änderung die neue Periode vollständig in die Zukunft versetzt, dann wird die neue Periode tatsächlich diejenige sein, die ‹ jetzt › enthält.
Hinweis: Die neue, kürzere Periode ist in der Regel vollständig in der vorherigen Periode enthalten, außer manchmal, wenn man zu einer Periode ‹ 7 Tage › wechselt
Ein kleiner Nachteil bei der Navigation im ‹ Zickzack › in mindestens zwei Fällen:
Zum Beispiel: 6-12/1 => 1-31/1 => 27/1-2/2 => 1-28/2 => 24/2-2/3 => 1-31/3 … Aber der Fall ist selten, und man wird schließlich auf einen Sonntag am Monatsende oder auf ‹ jetzt › stoßen, also scheint es nicht so schlimm zu sein…Hallo @StephaneB Danke, dass du dich mit diesem Thema beschäftigt hast!
Dein Vorschlag enthält einige gute Ideen, aber ich denke, dass die UI/UX noch etwas Arbeit verdient, um intuitiver zu werden.
Einige Rückmeldungen:
Bei dieser Art von Oberfläche, die es schon in vielen Anwendungen gibt, denke ich, dass wir uns wirklich von bestehenden Lösungen inspirieren lassen können. Kein Grund, das Rad neu zu erfinden Hast du dich auf konkrete Beispiele gestützt?
Danke, dass du dich darum kümmerst, meine Anmerkungen sind direkt, aber nichts Persönliches, haha!
Kein Problem, das passt mir gut
Ich würde ihn schon gerne haben Aber das reicht natürlich nicht, um daraus einen Gemeinschaftsbedarf zu machen. Ich wäre an den Meinungen der anderen interessiert, besonders derjenigen, die für dieses Thema gestimmt haben…
Ich verstehe… Also, ich bin kein Grafikdesigner, aber ich habe gerade versucht, Icons zu erstellen, um das Ganze intuitiver zu gestalten. Wenn es Grafikdesigner in der Community gibt, zögert nicht, etwas anderes vorzuschlagen
Um die Auswirkungen des Wechsels zwischen „Regulär“ und „Gleitend“ zu verdeutlichen, könnte es so aussehen:
und 
Und für die Rückkehr zu „Jetzt“, könnte es ein Icon in diesem Stil sein:
In einem Diagramm integriert, würde es so aussehen:
Was haltet ihr davon?
Wie ich bereits in meiner vorherigen Nachricht sagte, denke ich, dass wir uns an bestehenden Schnittstellen orientieren sollten
Bevor du neue Vorschläge machst, kannst du eine kleine Studie anderer Schnittstellen durchführen, in denen man ähnliche Muster findet?
Beispiel mit einem Tool, das ich täglich nutze, Stripe:
Ben oui, mais non…
Das Beispiel des Stripe-Dashboards erscheint mir nicht relevant: Es funktioniert mit einer Art Konfigurationsleiste, die verschiedene große Fenster öffnet, um den beobachteten Zeitraum und den Zeitraum für den Vergleich zu definieren, und was konfiguriert wird, gilt dann für alle Diagramme der Seite. Das ist überhaupt nicht die Logik von Gladys, und es erscheint mir überhaupt nicht relevant, die Konfigurationsmethode von Stripe in jedem der Diagramme eines Gladys-Dashboards ‹ sauber › zu machen.
Und außerdem bietet Stripe keine einfache Möglichkeit, in der Vergangenheit/Zukunft zu navigieren: Es gibt keine Vorherige/Nächste-Pfeile, um sich in der Zeit zu bewegen, obwohl das das Ziel dieser Anforderung in der ursprünglichen Mockup von @Tolkyen und auch in deiner ist…
Kurz gesagt, die Stripe-Oberfläche inspiriert mich überhaupt nicht, um Gladys weiterzuentwickeln…
Hast du andere Ideen für bestehende Oberflächen? Denn ich habe keine Ideen auf meiner Seite und keine Zeit, ‹ zufällig › zu erkunden… Wenn du mir andere Hinweise gibst, bin ich bereit, sie anzusehen
Alle dargelegten Möglichkeiten gefallen mir, danke @StephaneB für die ganze Arbeit
Ich habe mir auch gerade das von dir bereits erwähnte Interface von HelloWatt angesehen. Es ist sauber und intuitiv, aber im Vergleich zu dem, was wir in Gladys vorhaben, stark vereinfacht. Dort:
Daher ist es schwierig, ihr einfaches Interface beizubehalten, um die reichhaltigere Funktionalität von Gladys anzubieten.
Ich bin weiterhin verfügbar, um andere bestehende Schnittstellen zu untersuchen, die diese Art von Zeitverlauf auf Grafiken anbieten, um sich davon inspirieren zu lassen… Wer hätte Ideen?
Hallo @StephaneB
keine konkreten Ideen fürs Design im Moment, aber könnten wir nicht schon mal einige Funktionen implementieren, die bereits in Apexcharts vorhanden sind?
Ich weiß nicht so recht, wie ich dir antworten soll, @mutmut. Vielleicht sollte eher @pierre-gilles reagieren, je nachdem, was er über ApexCharts weiß? Da ich kein Entwickler bin, habe ich die ApexCharts-Dokumentation nicht durchforstet, um zu sehen, was bereits möglich ist.
Und das ist auch ein bisschen Absicht: Ich denke, dass man, um gute Software zu entwickeln, die Überlegungen zu den Anforderungen (was ich versucht habe) und die zur Umsetzung (die ich den Entwicklern überlasse) zunächst a priori trennen sollte. Und natürlich, wenn die beschriebenen Anforderungen technisch nicht vernünftig umsetzbar sind, muss man sich austauschen, um den richtigen Kompromiss zu finden
Aber zu diesem Thema stehe ich weiterhin zur Verfügung, um andere Schnittstellen zu erkunden, wenn ihr Ideen habt, und mich davon inspirieren zu lassen, um die Anforderungen, die ich skizziert habe, zu überarbeiten, oder um mit dem/den Entwickler(n) zu diskutieren, falls bestimmte von mir vorgeschlagene Punkte zu komplex umzusetzen sind.
Das Ziel ist nicht, exakt das zu kopieren, was Stripe, HelloWatt oder andere Produkte machen, sondern sich eher von bestimmten bewährten UI-Mechaniken inspirieren zu lassen, die gut funktionieren.
Bei Stripe zum Beispiel gefällt mir ihr Intervallauswahl-Tool: Es kombiniert feste Bereiche mit gleitenden Intervallen:
Ich finde ihren Ansatz klarer als dein Vorschlag.
Aber ich stimme zu, dass der Stripe-Auswahl-Tool für Gladys keinen Sinn ergibt, es ist nur ein Beispiel.
Ich kann Zeit in diese Spezifikation investieren, aber das hilft mir weniger 
Auf meiner Seite ist gerade meine ganze Energie auf Matter gerichtet.
Vollkommen einverstanden!
Die Implementierung ist ein Detail. Das Schwierigste ist die Spezifikation.
Danke @pierre-gilles für die Klarstellung
Okay, ich verstehe. Aber das heißt also, du bist einverstanden, wenn ich ein Mockup erstelle, das sich traut, Funktionen zu integrieren, die sich deutlich von der aktuellen Version unterscheiden? Denn bisher habe ich eher funktionale Vorschläge gemacht, ohne die Oberfläche zu stark zu verändern (um sowohl die grafische Entwicklung zu begrenzen als auch keine zu große „Bruchstelle“ in den Gewohnheiten der Nutzer einzuführen)…
Nein, das war nicht die Idee, ich möchte gerne weiter daran arbeiten. Ich habe nur nach Ansätzen gesucht, die man erkunden könnte, aber nicht nur von dir Ich werde selbst ein bisschen recherchieren, aber ich bin weiterhin offen für Ideen von allen für Websites, die „navigierbare“ Diagramme anzeigen und mich inspirieren könnten…
Schlag vor, was du möchtest
Ich weiß, dass das etwas umständlich ist, aber genau darum geht es bei der Spezifikationsarbeit 
Es ist kein Scherz, wenn ich sage, dass dies der komplexeste Schritt ist!
Man muss recherchieren: im Google stöbern, sich von Alltagsprodukten inspirieren lassen, die KI bei Bedarf fragen oder Websites erkunden, die UX-Patterns oder inspirierende Designbeispiele sammeln.
Also, ich muss zugeben, das ist ein Anwendungsfall, bei dem KI wirklich Zeit spart: Ich habe beschrieben, was ich tun wollte, und sie nach Beispielen von Websites und Komponenten gefragt… und das hat mir wirklich geholfen!
Dabei habe ich einige Dinge gelernt:
Daher reicht es, Folgendes zu platzieren:
Und für eine flüssige und logische Navigation muss eine automatische Synchronisation zwischen dem Diagramm und dem Auswahlmenü erfolgen. Das heißt:
Ich habe einige Konfigurationstests mit einer Komponente durchgeführt, die mir sympathisch erscheint und die die KI als gut kompatibel mit Gladys bezeichnet: DateRangePicker. Aber die Kompatibilität muss natürlich von @pierre-gilles oder anderen Entwicklern bestätigt werden
Mit dieser Komponente DateRangePicker habe ich die folgenden Optionen gewählt, um das untenstehende Mockup zu erstellen:
Und ich habe die gleitenden Zeiträume, die derzeit in Gladys existieren, vordefiniert, gefolgt von den äquivalenten kalendarischen Perioden
- Letzte 60 Minuten / Diese Stunde
- Letzte 12 Stunden / Dieser halbe Tag
- Letzte 24 Stunden / Dieser Tag
- Letzte 3 Tage / (Kein kalendarisches Äquivalent)
- Letzte 7 Tage / Diese Woche
- Letzte 30 Tage / Dieser Monat
- Letzte 90 Tage / Dieses Quartal
- Letzte 365 Tage / Dieses Jahr
(Falls benötigt, kann ich den Konfigurationscode des DateRangePicker, den ich verwendet habe, bereitstellen)
