Diskussion zur Strukturierung einer Doku-Seite

crunchip

Nicht falsch verstehen. du wolltest das man drüber schaut. Besser ist wenn mehrere drüber schauen, damit verschiedene Eindrücke entstehen.

Richtig, fasse ich auch nicht falsch auf, bin für jeden Tipp dankbar.

@oliverio sagte in Doku node.js Update:

damit demotivierst du diejenigen, die überhaupt etwas machen wollen und verhinderst das überhaupt etwas da ist oder entsteht.

Nicht sofort aber auf dauer ja,
das "Ding" ich nenne es mal so, steht mehr oder weniger seit über nem Jahr leer.
Ich weiss gar nicht wie oft ich das aufgeschlagen habe und mir die einzelnen Rubriken angesehen habe. Jedoch keinen Ansatz finden konnte, was wie wo hin soll.

Ich hatte auch den Vorschlag unterbreitet, es aufzuteilen, Einsteiger, Fortgeschritten, genauso wie ich der Meinung bin, was am gewichtigsten, schnellstens in die Doku muss, wenn man die vielen Foreneinträge betrachtet.

Es wurde schon sehr viel darüber geschrieben, man sollte, man könnte,...
Aber es passiert nichts.

Und nun freut es mich umso mehr, das plötzlich es den ein oder anderen gepackt hat, aktiv mitzuwirken und wenn das so bleibt, auch schnellsten ne vernünftige Doku zu stande kommt.
Perfektion mal aussen vor, den Feinschliff kann man immer noch anpassen, aber zumindest sind die Inhalte dann brauchbar gefüllt.

Jey Cee

@oliverio sagte in Doku node.js Update:

damit demotivierst du diejenigen, die überhaupt etwas machen wollen und verhinderst das überhaupt etwas da ist oder entsteht.

Das ist absolut nicht meine Absicht, aber es wurde nach Feedback gefragt.
Und das sind eben Kriterien nach denen ich eine Dokumentation bewerte, als Entwickler und Benutzer. Dabei spielt es für mich keine Rolle ob es um Software geht oder ein Kochrezept.

Ich hab damit auch nicht die Inhaltliche Qualität dessen was @crunchip erstellt hat Bewertet, dazu hätte ich es ganz lesen müssen und das hab ich nicht.
Was ich bewertet habe war der Aufbau und der entspricht einfach nicht dem was ich erwarte.

So viel Meinung sollte man ertragen.

crunchip

@jey-cee sagte in Doku node.js Update:

Und das sind eben Kriterien nach denen ich eine Dokumentation bewerte

Stehen die Kriterien irgendwo dokumentiert, nach denen man sich richten sollte?

@jey-cee sagte in Doku node.js Update:

hätte ich es ganz lesen müssen

Eben, dann demotivieren solche Sätze

@jey-cee sagte in Doku node.js Update:

ich hab drüber gesehen, also geöffnet und mehr oder weniger gleich wieder geschlossen.

Umso mehr

Aber unabhängig davon, werde ich mir die Vorschläge nochmal durch den Kopf gehen lassen und sehen wie ich es besser machen kann.

apollon77

Hey All,
Hey @crunchip,

ich finde es super das DU dir das Thema annimmst.

Jeder Content den wir dazu bekommen können ist super.

Wie man es am besten für alle Zielgruppen strukturiert ist denke etwas was wir lernen müssen. In dem Fall hier ist vllt eine Anleitung mit nur den Befehlen schwierig weil dann auch die User die nicht wissen was Sie tun zum vermeintlich kurzen/schnellen greifen "ohne zu wissen was Sie da tun" :-)
Ich denke auch das wir lernen werden wie was ankommt und können nachbessern.

Das Du hier um Feedback fragst ist super und ja dann kommt halt auch Feedback :-) Am Ende würde ich es aber erstmal so sehen wie bei der Adapter-Entwicklung auch: Im ersten Schritt gewinnt der der sich die Arbeit macht :-) (unter der Premisse natürlich das es generell sinnvoll ist was im Text steht :-) ) Der Verfasser entscheidet welches Feedback er wie verarbeitet. Keiner sollte sich durch Feedback angegriffen fühlen.

Und ich persönlich würde es aktuell eher pragmatisch sehen: Jeder (sinnvolle und zur Struktur/Idee passende) Content ist besser als keiner. Optimieren, Kürzen, Verteilen, Verschieben u.ä. können wir immer noch in einem zweiten Schritt. Wir können hier iterative arbeiten und sollten es auch ...

Ingo

crunchip

@apollon77 sagte in Doku node.js Update:

Das Du hier um Feedback fragst ist super und ja dann kommt halt auch Feedback

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.

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

@apollon77 sagte in Doku node.js Update:

In dem Fall hier ist vllt eine Anleitung mit nur den Befehlen schwierig weil dann auch die User die nicht wissen was Sie tun

Da wird es noch sehr oft zu Diskussionen kommen, denn bei einigen Themen ist es eben nicht mit ein paar Befehlszeilen und Fachbegriffen getan.
Zumal ich dachte, es soll Einsteigergerecht sein, dazu gehört eben auch ein wenig Hintergrundwissen dazu.
Und was viel wichtiger ist, wenn schon permanent immer der selbe Fehler XY bei vielen Usern auftritt, kann man das doch auch direkt gleich als Hinweis mit dran packen.

@apollon77 sagte in Doku node.js Update:

Optimieren, Kürzen, Verteilen, Verschieben u.ä. können wir immer noch in einem zweiten Schritt.

eben, denoch versucht man es ja so passend wie möglich umzusetzen.

daher,
da ich mir das nun nochmal in aller Ruhe zu Hause am Pc durchgelesen habe, bin ich dennoch etwas verwirrt

@jey-cee sagte in Doku node.js Update:

Ich finde es anstregend in einem so Wuchtigen Text nach einer Anleitung zu suchen

Die einzelnen Passagen werden doch rechts oben im Menü aufgeschlüsselt, ein klick darauf und man ist beim entsprechenden Part.
siehe Beispiel

@jey-cee sagte in Doku node.js Update:

Ein Sinnvoller Aufbau könnte sein das zuerst die Einleitung kommt, dann der Ablauf mit Erklärung und am Ende die Anleitung.

Einleitung ist vorhanden, (sollte zum Ausklappen sein, für denjenigen die es interessiert)
Ablauf mit Erklärung ist ebenfalls vorhanden und ist doch sogleich die Anleitung, nur das die ensprechenden Befehle dazu direkt bei stehen.

Somit hat der Leser den direkten Bezug/Info zum Befehl.

klapp ich nun alles mögliche mittels Dropdown zu und klatsch am Ende die "Befehlskette" zum abarbeiten hin, liest doch kein Mensch zwischen den Zeilen und kopiert nur wieder blind heraus ohne zu wissen, was er da eigendlich macht.

Jey Cee

@oliverio sagte in Doku node.js Update:

Du erstellst genau die gleiche Seite nach deinen Vorstellungen

So das hab ich jetzt mal gemacht, nur um zu Zeigen was ich meine.
Es gibt zu 100% Verbesserungsmöglichkeiten bei den Texten und es ist nicht Vollständig.
Für Mac fehlt die Anleitung ganz und Windows ist Unvollständig, aber die Zweite Anleitung war nötig um das Prinzip zu verdeutlichen.

Außerdem habe ich deutlich mehr Links eingestreut, zum Teil sind auch Links drin mit Platzhaltern.
Ich seh keinen Sinn darin etwas zu beschreiben was jemand anders bereits beschrieben hat.

Btw. das bisschen hat mich jetzt 5 Stunden gekostet und es ist weit weg von Perfekt. Das ist der Grund warum ich sowas normal nicht mache.

https://github.com/Jey-Cee/ioBroker.docs/blob/master/docs/de/install/updatenode.md

@crunchip sagte in Doku node.js Update:

liest doch kein Mensch zwischen den Zeilen und kopiert nur wieder blind heraus ohne zu wissen, was er da eigendlich macht.

Genau das passiert auch so wie du es geschrieben hast. Nur das die User dann halt schnell mal einen Befehl übersehen und damit zu 100% in Probleme Laufen. Da Spreche ich aus Erfahrung.

Übrigens finde ich das deine Einleitung sehr gut auf die Seite Architektur passen würde. Das was da jetzt zu Node.JS steht ist Mager.

crunchip

@jey-cee sagte in Doku node.js Update:

nur um zu Zeigen was ich meine

ich danke dir für deine Mühe:+1: ich habe es kompett gelesen und auch mehrmals

aber

@jey-cee sagte in Doku node.js Update:

zum Teil sind auch Links drin mit Platzhaltern.
Ich seh keinen Sinn darin etwas zu beschreiben was jemand anders bereits beschrieben hat.

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. Deshalb habe ich das auch nicht verlinkt.

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.

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.

deinen Aufbau habe ich schon verstanden, doch machst du es dir damit recht einfach, denn Punkte wie

Update innerhalb einer Version (apt update && apt upgrade)
ist auch sehr wichtig, gerade beim radar2 und ble Adapter) weil die benötigten setcup... Befehle gesetzt werden müssen, was mittlerweile auch der iob fix bereinigt
js-controller, nicht jeder ist auf aktuellem Stand, selbiges gilt fürs
Betriebssystem
Problemlösung, wenn es nicht geklappt hat, bzw wenn die Vorraussetzung gar nicht gegeben ist, wie in meiner unter Vorbereitung Punkt 1 zu finden

gerade im Bezug auf die richtigen Pfade, doppelte Installation/ verschiedene Versionsinstallationen, was sehr vebreitet ist, gehst du gar nicht ein. Deine Dokumentation geht vom reinen Idealfall aus.

gehe ich in den Laden und kaufe mir einen Verstärker, pack den zu Hause aus, darin finde ich ein zusammen gefaltetes Blatt mit der Aufschrift "Schnellinstallation", daneben liegt ein kleines Buch mit dem Titel "Benutzerhandbuch"

Was von beiden soll die Doku hier werden??

@jey-cee sagte in Doku node.js Update:

Übrigens finde ich das deine Einleitung sehr gut auf die Seite Architektur passen würde. Das was da jetzt zu Node.JS steht ist Mager.

stimme ich dir zu, jedoch gehört zur Architektur noch viel mehr dazu als Node.js, das ist ne andere Hausnummer,
ich habe mir bewusst das Thema Update Node.js herausgesucht

AlCalzone

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 🤣

apollon77

@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.

apollon77

@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.

Homoran

@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)

apollon77

@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

AlCalzone

@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 1

Schritt 2:
Erklärung und Hintergründe zu Schritt 2

...

Anleitung & Befehle:

Schritt 1:

npm do 1 thing
apt something else

Schritt 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.

crunchip

@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?

apollon77

@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

crunchip

@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.

Jey Cee

@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.

Homoran

@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 werden

Dieses 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

crunchip

@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.

Jey Cee

@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.

Community Forum

NEWS

Diskussion zur Strukturierung einer Doku-Seite

Support us

382

32.5k

81.6k

1.3m