Ich sehe immer mehr Leute, die im Forum um Hilfe bitten, und es ist immer schwierig, das Problem ohne ein Minimum an Informationen zu verstehen.
Ich schlage einen Button im Bereich Einstellungen > System vor, mit dem eine Datei (oder ein Text) extrahiert werden kann, die die Basisinformationen (Gladys-Version, Systemversion, Gerät, auf dem Gladys installiert ist) und einen Auszug der letzten Logs (pro Service?) enthält.
Dadurch könnten neue Benutzer im Forum leichter Hilfe erhalten.
Ich stimme dem Problem zu, nicht unbedingt der Lösung.
Kehren wir also zur Grundlage des Problems zurück.
Welche Arten von Benutzerproblemen begegnen uns im Forum?
Wenn du andere spezifische Fälle von Beiträgen im Forum siehst, sag mir Bescheid 
Bei 1. handelt es sich um ein Kommunikationsproblem: Unsere Dokumentation ist nicht reichhaltig genug und der Benutzer dachte, es würde funktionieren, obwohl wir das Gerät nicht verwalten. Das Interface hätte ihn warnen können, indem es ihm sagt: « Kein Gerät erkannt. Ist Ihr Gerät in der Liste der verwalteten Geräte? [HIER LINK ZUR LISTE EINFÜGEN] ».
Bei 2. handelt es sich um ein Problem der Klarheit des Interfaces. Das Interface könnte mehr Rückmeldungen darüber geben, was der Backend-Code « sieht » in « roher » Form. Wir müssen serviceweise prüfen, wie wir das Interface mit genaueren Statusrückmeldungen der tatsächlich vom Backend empfangenen Daten klarer gestalten können. Beispiel: Im Fall von Xiaomi könnte man eine Liste der letzten 10 von Gladys empfangenen Nachrichten in quasi roher Form anzeigen.
Im Fall 3. reicht oft eine einfache Beschreibung, wie der Bug reproduziert werden kann, um ihn auf der Entwicklerseite zu reproduzieren.
Das Problem, das ich mit einer Lösung vom Typ « wir exportieren eine Datei der Gladys-Instanz und der Benutzer stellt sie ins Forum », ist, dass wir den Benutzer dazu ermutigen, beim Debugging passiv zu sein, und dass wir den Benutzer in eine Beziehung « Benutzer ↔ Kundensupport » mit dem Forum bringen. Die Datei wird wahrscheinlich ein großer Block voller technischem Jargon sein, den der Benutzer nicht lesen wird (weil er für einen Nicht-Eingeweihten unleserlich ist), er wird ihn einfach ins Forum kopieren.
Das Ergebnis? Die Supportlast im Forum wird nur zunehmen, und die Benutzerzufriedenheit wird paradoxerweise sinken, weil der Benutzer auf eine Rückmeldung eines « Experten » warten muss, ein « Experte », der nicht verfügbar sein wird, weil er zu viele Anfragen zu beantworten hat.
Was ich mir eher vorstelle
Der Benutzer sollte meiner Meinung nach alle Schlüssel in der Hand haben, um im Produkt zu sehen, was nicht stimmt, und so selbst an der Problemlösung mitwirken zu können.
Wir müssen serviceweise die häufigen Blockaden identifizieren und im Interface mehr klare Nachrichten (Fehlermeldungen, Informationen) für jeden identifizierten Blockadepunkt hinzufügen.
Für einfache Verständnisprobleme (was ist mit Gladys kompatibel?), müssen wir besser zur Dokumentation umleiten, anstatt zum Forum, damit der Benutzer sich selbst helfen und seine Antwort ohne Wartezeit erhalten kann
Was denkst du?
Ich weiß, dass mein Beitrag für die einfache Funktion, die du verlangst, sehr umfassend sein kann, aber ich denke, es ist entscheidend, die richtigen Grundlagen zu schaffen, um unnötige Supportstunden zu vermeiden, wo ein einfacheres Interface oft ausreicht. Es sind solche einfachen UX-Entscheidungen, die dazu beitragen werden, dass die v4 auf mehrere tausend Benutzer skaliert werden kann oder nicht.
@VonOx @AlexTrovato ich tagge euch hier, ich denke, es gibt ein großes Projekt, das auf diesem Thema ansteht.
Aktuell haben wir wirklich keine Informationen, wenn etwas mit bestimmten Integrationen (Z-Wave, Bluetooth, Xiaomi) nicht funktioniert. Es muss eine echte Überlegung angestellt werden, damit wir das Debugging erleichtern können, immer im userfreundlichen Geist der v4 und mit maximaler Freiheit für den Nutzer, damit er selbst eine Idee davon bekommt, was nicht funktioniert.
Ich nehme ein einfaches Beispiel: der Xiaomi-Dienst.
Zusammenfassung der Anfragen, die wir haben:
Ich denke, wenn wir an der UI arbeiten, anstatt auf das Forum zu verweisen, profitiert jeder davon: Der Nutzer findet seine Antworten im Produkt, und wir werden weniger für kleinere Probleme kontaktiert.
Ich bin absolut einverstanden, dass verhindert werden muss, dass das Forum zu einem Kundensupport wird. Das ist sehr zeitaufwendig und manchmal sogar infantilierend für die Nutzer.
Mir gefällt die Idee, dass die Dienste bestimmten Benutzerinteraktionsnormen entsprechen. Ich denke, wir alle haben die technische Vision, aber die Benutzerfreundlichkeit erfordert einige Anstrengungen, um die Nutzung zu erleichtern.
Und man spürt in dieser Version 4 die Richtung, die du vorgeben möchtest. Das Komplizierte bei der Integration von Hardware ist die Vielfalt der Geräte und der Fehlerfälle.
Ich werde versuchen, eine zusätzliche Hilfeseite in der Dokumentation vorzuschlagen, mit einem Leitfaden zur Identifizierung der Hauptprobleme und zur Förderung der Eigenständigkeit der Nutzer.
Man könnte auch eine FAQ am Ende der Integrationsseiten hinzufügen (z. B. für Xiaomi-Gateways).
Ich denke auch, dass man Anfänger, die einfach nur installieren und alles mit einem Klick konfigurieren wollen, von denen unterscheiden sollte, die entwickeln können, Logs lesen, sich mit Docker verbinden usw.
Beide Kategorien werden profitieren, wenn es mehr Informationen in Gladys (Dokumentation und Produkt) gibt, und die zweite Kategorie wird vielleicht mehr Lust haben, Fehler zu verstehen/zu beheben oder zusätzliche Integrationen in Angriff zu nehmen.
die Frage ist: Wenn du eine App auf deinem iPhone installierst, hast du dich schon mal auf eine Bedienungsanleitung bezogen? Ich persönlich: nie 
Alles funktioniert und wenn es einen Bug in einer App gibt, sagt mir die App das in der App: Das muss auch bei Gladys so sein.