ioBroker User-Onboarding/-Flow Verbesserungen 2022
-
Hi all,
ich hatte versprochen im Rahmen des "Hardware Tab"-Themas mir mal Gedanken zu machen wie man das sinnvoll in eine User-Story packt. In dem Zuge bin ich noch über andere Themen gestolpert, daher hole ich hier mal etwas weiter aus. Damit wird das Gesamt-Thema "etwas größer" was das "Ziel" angeht. Umsetzen kann man hier aber schrittweise und ggf. auch parallel, also lasst Euch davon nicht abschrecken!
ioBroker Erste Schritte eines Users ... Reality
Der aktuelle "On Boarding Prozess" für User ist bei uns - gelinde gesagt - suboptimal und unvollständig:
- User installiert ioBroker mit Installer, alles super
- Er geht auf die Webseite und hat den Einrichtungs-Wizard für Settings und Password und so, auch noch alles gut
- Er landet bei Discovery im Rahmen des Einrichtungs-Wizard und bekommt neben Adaptervorschlägen zu gefundenen Geräten (unvollständiger als man es sich wünscht, aber das ist eine andere Baustelle) auch ein paar andere sinnvolle Adapter vorgeschlagen, auch gut bzw ok weil man hier Vorschläge essentieller Adapter vllt besser/anders darstellen kann
- Dann landet er in der Admin UI (auf der Übersicht-Seite?) ... und ist erstmal allein gelassen
Das Thema Adapter und Instanzen erschliesst sich dem User vllt noch von selbst, den Rest muss er Erkunden.
... und daraus entstehen ein paar "Pitfalls"
Wenn ich so nachdenke fallen mir da die folgenden Pitfalls ein (Liste garantiert nicht vollständig)
- Wir wollen am Ende das User anstelle den direkten Instanzobjekten doch besser Aliasse nutzen, der Devices Adapter wird aber (noch) nicht installiert oder vorgeschlagen.
- Devices, aber auch iot, material und sowas brauchen gepflegte Functions und Räume bei den Objekten ... das sagt dem User aber niemand und unter "Enums" muss man das doch eher suchen.
Ich glaube der hm-rpc/rega-Adapter ist fast die einzige Option wie User zu Räumen bzw. Funktionen kommen weil dort die aus Homematic importiert werden. Sonst sind die Enums erstmal leer. Ergo - ich glaube fast keiner nutzt Enums - Wenn der User nun Räume und Funktionen kennt, so muss er das aktuell mühsam über den Objekte Tab zuweisen ... machen auch wieder wenige bzw. man muss es erstmal finden.
- Dann kommt das Thema das jeder Adapter die "physischen Geräten"-Konfig anders macht, einige importieren alles, andere discovern und wieder andere haben in der Adapter-Konfig Tabellen, Listen oder große UIs. Das Thema kennen wir ja schon
- Funktionen zuzuweisen ist eine nervige Angelegenheit. Am Ende vllt auch unnötig weil wir ja idealerweise Rollen haben oder andere Möglichkeiten den Typ eines Gerätes zu erkennen ... warum es den User machen lassen?
Last but not least finde ich, dass unsere Tabs gerade ein wilder Mischmasch aus "Konfiguration" (braucht man selten) und "Operativ" (braucht man regelmäßig) ist und wir es ggf. damit dem User schwer machen die Übersicht zu behalten. Von "ausgelagerter Konfiguration in Tabs (z.B. Ham-Adapter - noch welche?) mal noch nicht angefangen. Das kann man vllt besser machen.
Was kann man da jetzt tun?
Daraus hätte ich mal folgende Themen abgeleitet, die man mal angehen kann/sollte, um in Summe etwas runder zu werden:
Thema 1: Sinnvolle/Standard Adapter besser vorschlagen
- Änderung Discovery-Flow Einrichtungs-Wizard Admin
- Themenspezifische Diskussion: https://forum.iobroker.net/topic/56309/diskussion-1-sinnvolle-standard-adapter-besser-vorschlagen
Der Einrichtungsassistent könnte "im Rahmen Discovery" nach der "Geräteerkennung" eine extra Seite haben um z.B. JavaScript, Node-Red, Scenes und vllt Text2Command oder so kurz vorzustellen und so "zielgerichtetere Vorschläge" für sinnvolle Adapter zu machen. Da müsste man mal überlegen welche der anderen Adapter noch Sinn machen etwas "zielgerichteter darzustellen". Damit kann man auch auf eine Default-Installation von Adaptern verzichten und lieber über solche Empfehlungen arbeiten. Auch iot und cloud könnte man so erklären und der User kann entscheiden ob er es braucht. Vllt sogar "Datenhistorisierung". Vllt dann besser auf einer Wizard seite mit "Aufklappbereichen je Adaptertyp" oder so mit ein bissl mehr "Content" bei Core-Adaptern und dann noch die sonstigen empfohlenen Adapter aus Discovery hinzufügen.
Thema 2: Räume und Funktionen bekannt machen
- Änderung Einrichtungs-Wizard Admin
- Themenspeezifische Diskussion: https://forum.iobroker.net/topic/56310/diskussion-2-räume-und-funktionen-bekannt-machen
Der Einrichtungs-Assistent sollte eine Seite haben, wo der User direkt im Einrichtungs-Flow mit dem Räume und Funktionen-Konzept vertraut gemacht wird. Idealerweise kann er direkt im Wizard aus einer vorgefertigten Liste jeweils auswählen was ihm gerade einfällt und was er braucht bzw. das auch um eigene Räume bzw Funktionen ergänzen. Und der Begriff "Enum" sollte hier bereits erwähnt sein für ein späteres wiederfinden - aber allein beim durchklicken findet er jetzt "bekannte" Dinge.
Thema 3: "Physical Devices and Services"/"Things" als Strukturebene inkl. Management ausserhalb des Objekte-Tab anbieten
- Änderung im Admin oder als eigener Adapter...
- Themenspezifische Diskussion: https://forum.iobroker.net/topic/56311/diskussion-3-things-als-strukturebene-inkl-management
Da haben wir ja schon die Idee des "Hardware Tabs" in der Diskussion unter https://forum.iobroker.net/topic/47053/generische-geräte-verwaltung mit dem "Device Management"-Proptypen von @UncleSam gehabt.
Namenstechnisch waren wir da noch nicht ganz einig in den letzten Diskussionen. "Hardware-Tab", "Device Management" sind zwei Begriffe. Am Ende sind es "Physical Devices and Services" - oder bei OpenHab "Things" (der drückt es eigentlich perfekt aus ... sollten wir den Namen einfach auch nehmen?).
Die Idee ist, das in einem neuen Tab jede Instanz seine "Geräte" aka "Physical Devices and Services" zeigt und spezifisches Management dieser zulässt (wenn relevant). Durch die Erweiterung um "Services" wird das Konzept etwas erweitert um hier für die User, meiner Meinung nach, eine sinnvolle runde Sicht und eine Abtrennung zu den "Virtuellen Geräten" (Aliasses) zu haben. Daher die Idee etwas erweitert gedacht:
- Dieser Tab listet alle Instanzen auf die es gibt (per io-package gibt es ein opt-out für Logikadapter und so)
- Wenn man eine Instanz aufklappt wird geprüft ob der Adapter die DeviceManagement-API unterstützt (io-package Flag).
- Wenn ja, dann liefert der Adapter-Backend-Code die Liste der Devices und möglicher Aktionen und alles wie im DM-Prototyp gezeigt. Der Entwickler liefert die Daten und Konfiguration und der Tab regelt die Darstellung. Pairing-Prozesse können als Flows umgesetzt werden und so weiter. Jedes Device kann aufgeklappt noch weitere Infos und Aktionen (zusätzliche Button-Leiste unter den Detail-Daten) anbieten. Weiterhin brauchen wir noch pro Device sein device-Objekt als ID in den Daten (das ist neu - wofür diese gleich)
- Wenn nein, dann sucht der Tab nach "device" Objekten in der Instanz und stellt diese als Liste da, damit haben wir in jedem Fall den Namen und ggf. über die Status-States noch Error und Connected Flags. Ggf machen wir noch ein "Allow delete" o.ä. Flags ins Objekt, womit man steuern kann was hier an Default-Funktionen angezeigt werden soll. Dazu kommt ein Hinweis das man hier nicht viel tun kann und man mehr unter "Objekte findet" - aber man sieht "Things" (siehe gleich, da kommt noch was ...)
- Wenn keine Device-Objekte da sind (da sollten wir alle identifizieren und fixen, auch ein Wetter-Adapter stellt ein Device dar nämlich den Wetter-Service) dann kommt nur ein Hinweistext.
- In den angezeigten Device-Listen bauen wir eine Spalte ein, um den Raum des Gerätes einzustellen (bzw. anzuzeigen wenn einer gesetzt ist). Dafür haben wir dann je Device-Eintrag sein Hauptobjekt als ID und können dort den Raum setzen. Für eine Vielzahl an Geräten gilt, das Sie in EINEM Raum sind. Für Ausnahmefälle von Things, die auf Channel-Ebene in anderen Räumen sein können (Multi-Channel Aktoren in einer zentralen Verteilung oder so) haben wir immer noch die Option es unter "Objekte" einzustellen (oder eigentlich beim Alias - kommt noch), aber ich denke das wir damit einen Großteil der Realität abdecken (Und formal ist auch das Multi Channel gerät selbst ja in einem Raum :-).
Damit hat der User eine Sicht auf die "Things"/"Physical Devices und Services", die er einfach nutzen kann ohne bei "Objekte" rumklicken zu müssen. Und wir haben mal eben eine einfache und sinnvolle Möglichkeit Räume zuzuweisen.
Thema 4: "Funktionen"-Erkennung automatisieren
- Änderung im Type-Detector und Admin und Devices
- Themenspezifische Diskussion: https://forum.iobroker.net/topic/56312/diskussion-4-funktionen-erkennung-automatisieren
Sobald der Type-Detector ins Spiel kommt (iot, material, devices Alias-Anlage u.ä.) versuchen wir eh zu erkennen was das gerade für ein Gerät ist bzw. unterteilen Channels in verschiedene "virtuelle" Gerätetypen oder so. Die "Funktion" ist an sich auf Ebene eines solchen virtuellen Geräts (was ja die interessante Ebene ist) fast schon vorgegeben.
Wir bräuchten also im Rahmen der Enums bei "Functions" (oder im Devices Adapter?) eine Möglichkeit ein Mapping der Funktionen zu Rollen bzw. "Device-Templates" vorzunehmen. Damit muss keiner mehr auf Ebene der Instanz-Objekte Funktionen zuweisen, sondern wir erledigen das indirekt automatisch sobald einer der automatischen Wege genutzt wird. Wer es manuell pflegen will kann das immer noch tun, das sollte dann gewinnen.
In dem Zuge heben wir auch auf, dass die genannten Adapter nur Objekte mit Räumen UND Funktionen überhaupt beachten, sondern gehen vllt nur auf Räume als Minimumanforderung. Damit macht das wieder etwas mehr Sinn und ist sinnvoller für die User zu managen.Beim Anlegen und editieren von einem Device im Devices Adapter sollten wir in dem Zuge auch Raum und Funktion des virtuellen Geräts prominent änderbar machen.
(später) Thema 5: Auftrennung der Tabs in Einrichtung/Konfig und Operativ
Die Idee hier (und ja, die ist noch bei weitem nicht zu Ende gedacht, da muss noch mehr Hirnschmalz rein, deswegen würde ich die erstmal zurückstellen) wäre das man die Tabs die eher zur Einrichtung des Systems bzw. von Adaptern gehören und man nicht so oft braucht in einen bereich oben kommen den man zuklappen kann.
In diesem Bereich können wir dem User eine Guidance geben ala-
- Systemeinstellungen
-
- Discovery
-
- Enums
-
- Adapter
-
- Instanzen
-
- Things
-
- (Virtual) Devices
- darunter ggf speziell geflaggte Tabs von Adapter wie zb Ham-Tab oder so ... die dann ggf vom User sortierbar, aber 1-7 nicht - oder wenn es nur der Ham Adapter ist dann fliegts weg. Muss man generell mal aufräumen bei einigen Adaptern.
Der "operative" Bereich beinhaltet die Tabs die man häufiger braucht und die eher das System ausmachen wie JavaScript, Node-red, vis, ... und wie Sie alle heissen.
Kleines Dilemma was ich noch nicht gelöst habe ist das zB Adapter und Instanzen vom "oft nutzen" eigentlich Zwitter sind weil Sie zur Einrichtung gehören (vor allem "Adapter") aber man Sie auch oft nutzt ... Vllt hat hier jemand ne Idee.
Fazit
Das wäre so eine Kleine Vision bzw ein Ziel meinerseits, was ich persönlich sinnvoll finden würde und der "Hardware Tab" (aka Things) ist da perfekt eingebunden mit einem Mehrwert auch für die User und nicht nur für die Devs
Idealerweise fühlt sich iobroker dadurch nicht mehr ganz so komplex an für neue User (und auch Bestandsuser), weil er ist es nicht. Und Bestandsuser bekommen neue Möglichkeiten - aber alles optional, weil Sie weiterhin so arbeiten können wie bisher.Ich habe lange überlegt wie man das Thema jetzt sinnvoll und übersichtlich diskutiert. Ich schlage vor Kommentare zu den einzelnen Themenbereichen (1-4, 5 lassen wir für später) und wie man diese konkret ausgestaltet in eigenen Threads diskutieren ... hier in dem Thread diskutieren wir eher "generelles" (ja ich weiss das es sich mischen wird, müssen wir alle ein bissl diszipliniert sein). Wir starten die Diskussion erst einmal im "Entwickler" Bereich was nicht heisst das nur Entwickler antworten dürfen oder Ihre Meinung sagen sollen, aber hier hat es angefangen
Jetzt bin ich gespannt über Eure Gedanken und Reaktionen zu meinen gesammelten Ideen ...
Ganz wichtig ist auch: Effektiv hat keines der Themen eine Abhängigkeit zu einem anderen. Damit ist auch keine Reihenfolge vorgegeben. Wir können Themen nacheinander oder - wenn Leute da sind die sich um einzelne Themen kümmern - auch parallel angehen.
Danke
Ingo
-
@apollon77 Super, dass Du Dir so tiefgreifende Gedanken machst.
Nach 4 Jahren Iobroker Nutzung habe ich noch nie eine ENUM vermisst oder benötigt, vermutlich, weil ich überhaupt nicht weiß, was ich damit anfangen soll. Auch Räume nutze ich überhaupt nicht. Bei Räumen kann ich mir schon eine Anwendung "konstruieren".
Gibt es eine Beschreibung der Anwendung für diese Datenstruktur?
-
@marty56 sagte: habe ich noch nie eine ENUM vermisst oder benötigt
Ich auch nicht. Seit es Alias gibt, benötigt man die Enums erst recht nicht, denn man kann die Objekt-IDs entsprechend strukturieren.
-
@apollon77 Ich bemerke, dass ich den Text oft mehrfach lesen musste, weil ich ihn nicht sofort verstanden habe. Das liegt auch an fehlenden Satzzeichen und Rechtschreibfehlern.
Ist es möglich, dass ich Schreibrechte auf den Text bekomme und dann die Fehler korrigiere. Das würde anderen helfen, die Texte besser zu verstehen.
-
@marty56 Danke für Dein Feedback... sowas hatte ich durchaus angenommen (also nicht auf dich, sondern generell bezogen)
Am Ende ist das die "logische" Sicht auf ein Smart Home, was meistens ein Haus oder eine Wohnung ist. Damit hast Du "Räume" die am Ende "Geräte gruppieren" auf diese Sicht. "Funktionen" ist quasi eine zweite (unabhängige aber kombinierbare) Strukturebene nach der Gerätefunktion - ist es Beleuchtung oder Verschluss oder Klima (Heizung) oder sowas.
Viele User wollen gute Visualisierungen Ihres Heims, aber so wenig wie möglich konfigurieren. Ähnlich bei Amazon oder Google und den Smart Assistenten. Daher ist dort wichtig zu wissen WO ein Gerät ist oder WAS es tut.
Über Enums kannst du neben diesen zwei Ebenen noch beliebige Weitere anlegen und dann in Skripten nutzen o.ä.EDIT: neben Visus die mit den Ebenen sinnvolle Ansichten automatisch bauen können hilft es auch in Skripten weil du ggf nicht mehr wissen muss was welche ID wie ist sondern einfach sagst "Ich gehe in den Urlaub; alle Beleuchtung aus, Rolladen runter und heizungen auf 10 Grad" ... oder so
-
@marty56 sagte in ioBroker User-Onboarding/-Flow Verbesserungen 2022:
Das liegt auch an fehlenden Satzzeichen und Rechtschreibfehlern.
ich gebe zu, dass ich den Post auch mehrfach gelesen habe, weil ich bei der Menge an Informationen immer wieder etwas übersprungen habe.
Aber bis auf einzelne Kommata ist mir nichts wirklich gravierendes aufgefallen. Schon gar nichts was das Verständnis behindert.
-
@paul53 Ich bin ehrlich: Auch ich nutze aktuell keine Enums - hab mir ein paar durch Homematic Import "eingefangen", aber gepflegt ist das nicht.
Ob ich es nutzen würde wenn ich es sinnvoll und ohne Aufwand pflegen würde ... vllt ja
Aber bei mir kommt auch mein eigenes System sehr stark zu kurz aus anderen Gründen -
Wenig neues für mich, vieles von dem was du geschrieben hast wurde auch früher schon angesprochen.
Worüber ich mir vor kurzem Gedanken gemacht habe ist die Erweiterung des Ersteinrichtungsassitenten. Speziell das man hier gleich zu Anfang nach den Räumen gefragt wird. Aber auch das man parallel zum Automatischen finden von Hardware einfach den User frägt was er so hat.
Damit könnte man die Automatisch Erkennung um die Adapter ergänzen für die es die Möglichkeit gar nicht gibt.
Hacken daran ist das man dann in irgendeiner Form Daten bereit halten muss wie zum Beispiel Model XY funktioniert mit Adapter X.Sonst war das ziemlich viel auf einmal und ich muss mir das nochmal durchlesen. Da kommt bestimmt noch mehr.
-
@apollon77 Als nicht mehr ganz so neuer Nutzer und Moderator auf Discord kann ich Dir nur zustimmen: Deine Vorschläge würden den Einstieg für viele Nutzer deutlich vereinfachen!
-
@jey-cee sagte in ioBroker User-Onboarding/-Flow Verbesserungen 2022:
Hacken daran ist das man dann in irgendeiner Form Daten bereit halten muss wie zum Beispiel Model XY funktioniert mit Adapter X.
Dann müsstest du ja mehr oder weniger für jedes Gerät (auch für das obskure Fernost-WhiteLabel-Tuya-Zigbee-Zeug) eine Gerätedatenbank pflegen. Das wäre aber ein Haken groß wie ein Anker.
-
@thomas-braun Ich glaube es gab mal versuche solche Datenbanken aufzubauen ... ich glaube aber das ist weitestgehend eingeschlafen weil die User Ihr Zeit da nicht eintipseln/melden sondern sich einfach freuen das es tut ... oder irre ich mich da und hab Dinge verpasst?
Aber ja klar ... man kann zb die Top X Adapter auch was Geräte-"Hersteller" bzw "Protokolle" angeht prominenter Darstellen. Also in meiner Idee gesprochen: Ein Aufklappbereich könnte sein "Protokolle" Zigbee, Zwave, EnOcean, Homematic - aber noch VIIIEEELL besser wäre wenn erkannt wird ob ein solcher Stick dran steckt und wenn dann kommt die direkte Empfehlung ...
Was andere Varianten angeht wie "Hast du Tuya geräte?" ... hhmm... Zigbee oder SmartLive-App? Da fängt es schon an schwieriger zu werden ...EDIT/PS: Aber ja ... vllt eine testsuche über die "tags"/"begriffe" der package.json der adapter ....wenn die ENtwickler das sauber pflegen kann man darüber schnell arbeiten ... vllt auch nee idee für "Adapter-Seite" das man beider suuche auf solche Begriffe mit berücksichtigt und nicht nur nach dem namen geht
EDIT2: Idee hier übertragen in Diskussionsthread 1
-
@thomas-braun jaein, da lässt sich einiges Automatisieren. Aber am Ende bleibt viel Handarbeit und die muss jemand machen.
-
@jey-cee sagte in ioBroker User-Onboarding/-Flow Verbesserungen 2022:
Aber am Ende bleibt viel Handarbeit und die muss jemand machen.
Ich glaube es wird dich nicht verwundern, wenn ich vorhersage: Die Handarbeit macht keiner dauerhaft.
-
daher sollte es nicht unbedingt vollautomatisch laufen, sondern eine "geleitete manuelle" wäre vollkommen ausreichend.
