Diskussion zur Strukturierung einer Doku-Seite
-
Mal abgesehen vom genauen Inhalt, Umfang und ob Verlinkung oder nicht... ich denke hier stehen zwei grundlegende Konzepte gegenüber:
- @crunchip's Ansatz, Befehle im Kontext von Erklärungen unterzubringen
- @Jey-Cee's Ansatz, erst zu erklären und dann kompakt die Befehle aufzulisten
Ich persönlich bevorzuge 2., weil es mmn. alle User gleichermaßen abholen kann:
- Die Profis, die wissen was sie tun und nur die Befehle nachschlagen wollen. Die können die Erklärung überspringen und sich aus den Befehlen das rauspicken, was sie brauchen.
- Die Anfänger, die erst mal genau lesen, was sie warum tun und danach das "wie".
- Und die Ungeduldigen, die sowieso nicht richtig lesen - die können wie die Profis die Befehle kopieren und ausführen. Da wird dann ggf. der ein oder andere Befehl zu viel ausgeführt, aber wenigstens keiner zwischen den textreichen Absätzen übersehen, was das troubleshooting im Anschluss einfacher macht
-
@crunchip sagte in Doku node.js Update:
da spricht nichts dagegen, die Art und Weise ist entscheidend. Statt "herab lassend" zu kritisieren, wäre es wünschenswert, wenn ein "alter Hase" dem "Neuling" konstruktiv und unterstützend unter die Arme greift.
Da bin ich bei Dir. Ich denke es war von @Jey-Cee nicht so "ruppig" gemeint wie man es lesen konnte
Vor allem bei diesem Thema "Doku" gibt es wahrscheinlich noch mehr Meinungen als bei anderen Themen und diese kommen aus "Zielgruppen-Sichten" (jeder gehört einer irgendwie an - oder mehrere). Da müssen wir uns bitte alle zwingen neutrales und konstruktives Feedback zu geben. Das würde ich mir wünschen.Gerade bezüglich auf den screen unten, Redis Datenbank, dachte ich mach dir einen gefallen, hab deine Infos aus dem Forum und den Rest aus dem Internet zusammen geklaubt, du hast mir noch Tpps gegeben dass das ein oder ander noch mit aufgenommen werden sollte, hast den ein oder anderen Satz noch etwas umformuliert und fertig war der Lack, zack und eine Seite mehr in der Doku, ohne gross Tam Tam
Und da ist eine super Idee und Danke dafür! Ja, wir haben einige "etablierte" pPosts im Forum die gut Vorlage für solche Dokus sein können.
-
@jey-cee sagte in Doku node.js Update:
https://github.com/Jey-Cee/ioBroker.docs/blob/master/docs/de/install/updatenode.md
Dieser Ansatz der Aufbereitung ist auch eine sehr gute Möglichkeit. Finde ich sehr übersichtlich und auch für die User Zielführend. Kontext als erstes,dann die Kommandos je nach Platform, dann Troubleshooting. macht für mkch vom Aufbau her Sinn.
Ich denke das sind genau die Diskussionen die wir neutral und zielgerichtet brauchen um "Best Practices" zu finden die wir dann auch auf andere Themen anwenden können.
-
@alcalzone sagte in Doku node.js Update:
Ich persönlich bevorzuge 2., weil es mmn. alle User gleichermaßen abholen kann:
und genau das bezweifle ich, dass damit auch Einsteiger abgeholt werden.
Ich behaupte mal, dass für dich als Hardcore-Entwickler der Blickwinkel ähnlich wie der von @Jey-Cee ist.@crunchip hat dazu ja bereits vieles geschrieben, wo ich aus Einsteigersicht nur zustimmen kann.
Für Profis und Ungeduldige mag die Version von @Jey-Cee die bessere sein. Aber geau so etwas hatte ich erwartet (und befürchtet)
-
@crunchip Als kleine Info: Der js-controller 4 wird nodejs Updates auch bei minor/patch Versionen erkennen und beim start die caps selbst so setzen wie es "iob fix" auch schon tut. Und der controller 4 sollte, wenn alles klappt, auch die "rebuild" Probleme bei "serialport" hinbekommen ...
Nichts desdo trotz sind die aktuellen Versionen draussen und ja der Artikel sollte auch solche Fälle abdecken
-
@homoran sagte in Doku node.js Update:
und genau das bezweifle ich, dass damit auch Einsteiger abgeholt werden.
Vielleicht bin ich da zu weit in der Materie und zu wenig im Support, aber (wieso) denkst du nicht, dass so ein Aufbau für Einsteiger geeignet ist?
Ablauf
Schritt 1:
Erklärung und Hintergründe zu Schritt 1Schritt 2:
Erklärung und Hintergründe zu Schritt 2...
Anleitung & Befehle:
Schritt 1:
npm do 1 thing apt something elseSchritt 2:
iob befehl 7 reboot
Eine Alternative wäre vielleicht beides in einem, aber den langen erklärenden Text in Spoiler zu verpacken. Wobei das dann wieder ganz schön viel geklicke bedeutet, wenn man es lesen will.
-
@apollon77 sagte in Doku node.js Update:
Als kleine Info: Der js-controller 4 wird
das Thema wollt ich an dem Beispiel js-Controller ebenfalls gerade noch ansprechen.
wie soll ein "aussenstehender" vernüftig eine Doku schreiben, wenn er das Hintergrundwissen, was in geraumer Zeit, Wochen/Monaten sich wo wie ändert, gänzlich fehlt. Man geht vom aktuellen Stand aus und beschreibt die aktuelle Situation. Version 4 macht dann einiges obsulet. Wie soll das bitte unter einem Hut gebracht werden? -
@crunchip Aktuell sind die Versionen <4 realität also schreibt man das. Sobald controller 4 in Stable kommt muss man das ggf anpassen und mit "gilt nur wenn" einbauen oder wie auch immer.
Am Ende gilt aber: Alles was vorher schon ging geht auch weiterhin ... also wenn jemand immer "iob fix "ausführt geht das ach mit controller 4 nicht kaputt. Von daher wird nichts "falsch" ... nur ggf "Nicht mehr so nötig".Ich denke sobald der Alpha Test startet vom controller 4 ist das Changelog so das man sieht was genau drin ist
-
@apollon77 sagte in Doku node.js Update:
Nichts desdo trotz sind die aktuellen Versionen draussen und ja der Artikel sollte auch solche Fälle abdecken
also lasse ich es auch so, wie ich es geschrieben habe.
@alcalzone sagte in Doku node.js Update:
Eine Alternative wäre vielleicht beides in einem, aber den langen erklärenden Text in Spoiler zu verpacken.
werde mir dazu mal Gedanken machen, wie es aussehen könnte, es ist m.M auch nicht zu pauschalisieren, das man etwas Einheitlich auf alle Themengebiete umsetzen kann.
@apollon77 sagte in Doku node.js Update:
Sobald controller 4 in Stable kommt muss man das ggf anpassen und mit "gilt nur wenn" einbauen oder wie auch immer.
ist unumgänglich, auch wenn wir gerade dabei sind, eine Doku auf die Beine zu stellen, einiges im Nachgang wieder angepasst werden muss.
-
@crunchip sagte in Doku node.js Update:
die Platzhalter führen in die Doku, die nicht gefüllt ist und laufen ins leere, da sehe ich das(mein) aktuelle Problem, wann wird diese Seite gefüllt.
Wenn du dir schon die Arbeit machst etwas Allgemeingültiges zu schreiben, was spricht dann dagegen es genau an der Stelle zu Platzieren wo es ohnehin stehen sollte?
Davon haben dann alle mehr und der nächste der die Seite Anfasst fängt nicht bei 0 an.@crunchip sagte in Doku node.js Update:
jedoch gehört zur Architektur noch viel mehr dazu als Node.js, das ist ne andere Hausnummer,
Klar gehört da mehr dazu, aber deswegen kannst du die Seite doch um deinen Text ergänzen.
@crunchip sagte in Doku node.js Update:
Nur noch auf Seiten zu verlinken, die man irgendwo im Netz findet, die der Linux Fremde dann auch wieder nicht versteht. Ich möchte den Einsteiger doch an die Hand nehmen, mit Beispiel zum Verständnis und mögliche Fehler zu vermeiden.
Naja man sollte schon Quellen wählen die Sinn machen. Und ich verstehe auch das man alles möglichst genau Erklären möchte, aber deswegen muss man nicht bei Adam & Eva anfangen oder das Rad neu erfinden.
Daher denke ich solange es mit entsprechenden Quellen Unterlegt ist, kann eine Erklärung sich auf den ioBroker Spezifischen Teil beschränken.@crunchip sagte in Doku node.js Update:
Desweiteren bin ich der Meinung, in dem Fall Thema Update Node.js sollte alles auf einer Seite sein und möchte nicht auf mehreren Seiten hin und herspringen müssen um mir alles zusammen zu suchen.
Gut, aber in dem Github Entwurf von dir verweist du ja selbst auf die Installtionsanleitung von Node.JS. Warum?
@crunchip sagte in Doku node.js Update:
Problemlösung, wenn es nicht geklappt hat
Steht am Ende und kann jederzeit erweitert werden. Es erscheint mir nicht besonders Sinnvoll schon am Anfang alle Möglichen Probleme auf zu Zählen samt Lösung.
@crunchip sagte in Doku node.js Update:
Deine Dokumentation geht vom reinen Idealfall aus.
Nein sie ist nur nicht Vollständig, das ist schon ein Unterschied. Aber es war auch nicht mein Ziel eine Vollständige Doku zu erstellen. Sondern eine andere Art von Struktur zu Zeigen.
@crunchip sagte in Doku node.js Update:
Was von beiden soll die Doku hier werden??
Das war meine Ausgangsfrage oder siehst du das anders?
Wir brauchen beides, entweder in einem oder getrennt. Für mich macht es Sinn beides zusammen zu haben.
Spart Arbeit und erleichtert es wenn man doch schnell mal was nach lesen muss. -
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Es erscheint mir nicht besonders Sinnvoll schon am Anfang alle Möglichen Probleme auf zu Zählen
Hast du mal ernsthaft versucht es mit den Augen eines hilfesuchenden Einsteigers zu sehen?
Dieser sucht wo er Hilfe finden kann, und ob dieser Beitrag für ihn der richtige ist.
Da muss er am Anfang abgeholt werdenDieses nur mal als Beispiel, das trifft noch auf andere Positionen in deinem Vorschlag zu.
Dieser ist sicherlich für Fortgeschrittene und Profis geeignet, holt aber Einsteiger nicht ab -
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Wenn du dir schon die Arbeit machst etwas Allgemeingültiges zu schreiben, was spricht dann dagegen es genau an der Stelle zu Platzieren wo es ohnehin stehen sollte?
Davon haben dann alle mehr und der nächste der die Seite Anfasst fängt nicht bei 0 an.Wie soll das bitte funktionieren?, Ich beginne mit einem Thema, in diesem wird Xyz angesprochen, jetzt muss ich erst mal xyz schreiben, damit ich mit meinem eigentlich weitermachen/verlinken kann. Und so zieht sich das duch mehrere Themen und nimmt kein Ende.
Letzendlich, habe ich aus gegebenen Anlass, weil einiges schon ausführlichst im Forum dazu nieder geschrieben wude, bewusst darauf verlinkt.@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
aber deswegen kannst du die Seite doch um deinen Text ergänzen.
könnte ich, hab aber keine Vorstellung wie, soll ichs einfach unten dran klatschen, oder sollte es zielgerecht eingebaut werden, was wiederum sehr viel zeit in Anspruch nimmt, da fehlt mir das Verständnis wie das funktionieren soll, wenn dann plötzlich jemand sich der Seite annimmt und selbst eine Beschreibung erstellt.
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Naja man sollte schon Quellen wählen die Sinn machen. Und ich verstehe auch das man alles möglichst genau Erklären möchte, aber deswegen muss man nicht bei Adam & Eva anfangen oder das Rad neu erfinden.
Daher denke ich solange es mit entsprechenden Quellen Unterlegt ist, kann eine Erklärung sich auf den ioBroker Spezifischen Teil beschränken.bin ich einfach anderer Meinung, wenn man mit der Materie noch nie etwas am Hut hatte, sind diese besagten Seiten dann ebenfalls nicht zielführend.
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Gut, aber in dem Github Entwurf von dir verweist du ja selbst auf die Installtionsanleitung von Node.JS. Warum?
damit man sieht woher es kommt
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Es erscheint mir nicht besonders Sinnvoll schon am Anfang alle Möglichen Probleme auf zu Zählen
wenn die installation schon im Vorfeld verbogen ist, nützt mir im Nachgang eine Problemlösung auch nur bedingt und hätte mir die dadurch entstehenden Probleme erspart
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Sondern eine andere Art von Struktur zu Zeigen.
habe ich wahr genommen
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Wir brauchen beides, entweder in einem oder getrennt. Für mich macht es Sinn beides zusammen zu haben.
Spart Arbeit und erleichtert es wenn man doch schnell mal was nach lesen muss.da sind wir einer Meinung, und ich habe es nun mal in meinem Entwurf, direkt zusammen gepackt.
-
@homoran jetzt mach mal halb Lang, du wirfst mir vor das ich zu Faul bin mir Hintergrund wissen an zu eignen.
Dann willst du aber jedem von Anfang erklären wie er zu einem Funktionierenden ioBroker inkl. allem drum und dran kommt. Servierst es dem User also auf dem Silbertablett.Was jetzt, soll man sich nun selber was aneignen oder vielleicht doch nicht?
Es gehört nun mal dazu ein gewisses Hintergrund wissen mit zu bringen oder es sich eben zu holen. Diesem Anspruch wird meine Art der Doku gerecht, den es wird jedem die Möglichkeit gegeben sich das Wissen an zu lesen. Man muss im ersten Schritt noch nicht mal eine Suche benutzen, dank Links.
Und genau damit ist eine der größten Hürden bereits genommen an der es eben oft scheitert.@homoran sagte in Diskussion zur Strukturierung einer Doku-Seite:
Hast du mal ernsthaft versucht es mit den Augen eines hilfesuchenden Einsteigers zu sehen?
Klar bin ich doch oft genug selber, nicht mehr bei ioBroker, aber bei anderen Dingen.
-
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
du wirfst mir vor das ich zu Faul bin mir Hintergrund wissen an zu eignen.
Nein! Das hast du falsch verstanden. Lies es nochmaal
-
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Dann willst du aber jedem von Anfang erklären wie er zu einem Funktionierenden ioBroker inkl. allem drum und dran kommt
die Grundkenntnisse und Fehlerquellen sollten einem Neueinsteiger ausführlichst dargestellt werden.
wenn dieser mit der Zeit sich ein wenig mit iobroker auseinander gesetzt hatt, fällt es ihm auch leichter und versteht Erweiterte Beschreibungen, dann besser.
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Es gehört nun mal dazu ein gewisses Hintergrund wissen mit zu bringen oder es sich eben zu holen
und das möchte man dem User doch aufzeigen, denn es setzt nicht gewisse Grundkenntnisse vorraus, falsche Denkweise
als ich einst auf iobroker stieß, war das durch Zufall, als ich eins dieser "kein Schimmer Video`s" gesehen hatte
mit Linux jedoch noch nie in Kontakt gewesen.
-
@crunchip sagte in Diskussion zur Strukturierung einer Doku-Seite:
da fehlt mir das Verständnis wie das funktionieren soll, wenn dann plötzlich jemand sich der Seite annimmt und selbst eine Beschreibung erstellt.
Das wird dir aber auch kaum jemand anderes vermitteln können. Bisher gibt es nämlich nichts ausformuliertes dazu.
Wer zu erst kommt, mahlt zuerst.
Die einzige Richtlinie die ich hier sehe, einfach nichts löschen von dem du dir nicht sicher bist das es weg kann.
Dank Github wäre es aber auch dann nicht Endgültig verloren.@crunchip sagte in Diskussion zur Strukturierung einer Doku-Seite:
Wie soll das bitte funktionieren? Ich beginne mit einem Thema, in diesem wird Xyz angesprochen, jetzt muss ich erst mal xyz schreiben,
Hä? Also entweder XYZ existiert oder du musst es schreiben, soweit logisch. Aber wenn du es doch schon geschrieben hast, weil du es in deiner Anleitung verwendest, stellt sich doch die Frage nicht mehr.
Es geht doch nur um Inhalte die du ohnehin geschrieben hast im Zuge der Doku die du gerade erstellst.@crunchip sagte in Diskussion zur Strukturierung einer Doku-Seite:
damit man sieht woher es kommt
Dann ist jetzt genau das passiert was ich als Kritikpunkt habe, ich hab die Befehle in deinem Text Übersehen.
-
@homoran sagte in Diskussion zur Strukturierung einer Doku-Seite:
Nein! Das hast du falsch verstanden. Lies es nochmaal
@homoran sagte in Diskussion zur Strukturierung einer Doku-Seite:
Keinen Hintergrund, keine verständnisfördernden Sachen - alles zu wuchtig. Ist dir alles zu anstrengend.
Vielleicht solltest du es nochmal lesen!
-
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Vielleicht solltest du es nochmal lesen!
ich wiederhole mich:
Das hast du falsch verstanden.Das waren deine Aussagen, was du in einer Doku nicht haben möchtest, weil es für dich zu anstregend sei, das zu lesen.
@homoran sagte in Diskussion zur Strukturierung einer Doku-Seite:
Du willst nur kurz nachschlagen, ... Keinen Hintergrund, keine verständnisfördernden Sachen - alles zu wuchtig.
Ist dir alles zu anstrengend. -
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Wer zu erst kommt, mahlt zuerst.
Bis dato standen Die Mühlräder eher still.
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Bisher gibt es nämlich nichts ausformuliertes dazu.
Zumindest ja jetzt die Arbeitsgruppen
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Hä? Also entweder XYZ existiert oder du musst es schreiben, soweit logisch
Verstehst du was ich geschrieben habe?
Ich beschreibe ein Thema, darin verlinke ich zu einem Part in der Doku, der noch nicht vorhanden ist.
Selber schreiben is nicht, da ich z.b- von dem Part keine Ahnung habe
- zu komplex ist was das drei oder vierfache an Zeit in Anspruch nimmt,
- in diesem Part wiederum Verlinkungen enstehen, die das selbe Auslösen und das zu einer Endlosschleife wird.
@jey-cee sagte in Diskussion zur Strukturierung einer Doku-Seite:
Dann ist jetzt genau das passiert was ich als Kritikpunkt habe, ich hab die Befehle in deinem Text Übersehen.
Über Struktur lässt sich reden, ich versuche die Tage mal, es etwas anders aufzubauen
Im übrigen steht der Installationbefehl doch klar und deutlich sichtbar im Absatz Akualisierung.
Ungünstig positioniert ist macos und Windows, weil ich das im nachhinein platziert hatte.
Das muss besser aufgeteilt werden -
@jey-cee
So ich auch noch.Also grundsätzlich würde ich die Doku eher für den Einsteiger sehen.
Fortgeschrittene haben schon eher die Fähigkeiten sich die Informationen da herauszulesen, im Forum zu schauen oder sich das Wissen selbst zu erarbeiten.
Viele Anfänger hier sind ja nicht nur im Thema iobroker neu, sondern auch wie betriebe ich einen Server oder gar neu mit Linux. Viele Begriffe, Befehle die im Forum so rumschwirren sind böhmische Dörfer. man hat überhaupt gar keine Ahnung was es bedeutet, viele haben eine zu kurze Aufmerksamkeitsspanne oder einfach zu wenig Zeit und Lust sich ausführlichts im Internet über alle Befehle vorzuinformieren, also wird einfach abgetippt was man irgendwo sieht und einigermaßen in die Problemstellung passt. Natürlich verstehen die meisten den genauen Kontext, warum der Befehl hier gerade eingetippt werden muss nicht.Daher denke ich, das man schon ein wenig mehr schreiben bzw. woanders hin verlinken muss.
@Jey-Cee Das Beispiel find ich ebenfalls gut, aber ist halt nur sehr knapp beschrieben und hilft den Fortgeschrittenen sicherlich als Merkzettel, was der Reihe nach abgearbeitet werden muss um ein Ziel zu erreichen.
Die Trennung von Text und Befehl finde ich allerdings nicht so gut, da man als Anfänger dann dauernd hin und her klickt und ggfs. auch mal einen Schritt überspringt.Wie wäre es mit einer Trennung in der Gliederung, so das die für Fortgeschrittenen relevanten Elemente schnell erkennbar sind und der Rest überlesen werden kann?
Wenn man so eine Gliederung standardisiert, so kann jeder sein Teil an Information leichter finden.Überschrift/Abschnitt/Schritt x
Beschreibung
<Hier der ausführlichere Text mit Links und ggfs. Bildern>
Befehle
iob fix
