In-Zeilen-Themensuche und -verknüpfung, z. B. Roam-ähnliche Klammer-Links

[oshyan (Oshyan Greene)]

Ich denke, es ist an der Zeit, dass Discourse eine schnellere Möglichkeit bietet, Links zu anderen Themen in einem bestimmten Forum zu erstellen. Offensichtlich gibt es bereits den vorhandenen Link-Button und die Tastenkombination im Composer, und wenn Sie wirklich brillant sind und zufällig die genaue URL eines Themas kennen, können Sie dies sogar ohne Verwendung des Link-Dialogs tun. Aber andere Anwendungen zeigen, dass es einen besseren, schnelleren und einfacheren Weg geben kann: Ein Aufruf eines Such-und-Link-Dialogs direkt im Textfluss.

In Discourse gibt es bereits Präzedenzfälle dafür mit dem @-Link/Such-Verhalten für Profile sowie dem #-Link/Such-Verhalten für Hashtags. Ich schlage daher einfach vor, eine Such-und-Link-Funktion für Themen hinzuzufügen. Dies würde einen sehr minimalen Ansatz verfolgen, ähnlich wie die @-Benutzersuche, mit einem schnellen Inline-Popup zur Themensuche basierend auf dem Text, den Sie im Composer eingeben, und würde keine Felder für Titel oder andere Steuerelemente enthalten. Es würde exakt wie die @-Suche funktionieren, nur für Links. Sie würden die Tastatur verwenden, um den Link zu bestätigen, und die erste Option wäre automatisch hervorgehoben.

Eine kürzlich populär gewordene Syntax dafür sind „Klammer-Links“, also [[link-zu-thema]]. Sie tippen [[ ein, und eine Suche nach Titel von Themen wird ausgelöst, genau wie bei den Benutzer- oder Hashtag-Suchen. Ein anderer gängiger Ansatz ist das /-Slash-Menü, das jedoch normalerweise für mehrere Funktionen verwendet wird. Wie auch immer es ausgelöst wird, es würde das Erstellen von Links zwischen Themen super schnell und einfach machen, was ich persönlich als etwas Positives betrachte, da es Menschen ermutigt, auf andere vorhandene und verwandte Inhalte zu verweisen.

Das Hauptproblem, das ich mit dieser speziellen Syntax sehe, ist, dass sie sich von der derzeit unterstützten Wiki-Syntax unterscheidet, aber auch ähnlich ist. Die Wiki-Link-Syntax wird jedoch tatsächlich in Systemen verwendet, die auch die Doppel-Klammer-Syntax [] unterstützen, aber speziell für Links, die benutzerdefinierten Text benötigen. Eine Option wäre also, dieselbe Unterscheidung zu verwenden: Doppelte Klammern für einen Link zu einem Thema, der den Titel des Themas als Linktext verwendet, oder einen traditionellen Wiki-Link für einen benutzerdefinierten Titel. Eine andere wäre, die Link-Syntax insgesamt zu ändern, was ich eher unwahrscheinlich finde. Eine dritte Option wäre, eine andere Inline-Link-Syntax zu wählen, also einen anderen Satz von Zeichen, der die Linksuche auslöst.

Es ist mir eigentlich egal, wie genau es implementiert wird; ich möchte einfach in der Lage sein, inline zu suchen und zu verlinken! Ich denke, es wäre eine großartige Ergänzung zum bereits hervorragenden Composer und den allgemeinen Komfortfunktionen von Discourse.

Das heißt, ich bin mir bewusst, dass die vorhandenen Composer-Funktionen sehr gut sind und dies nur ein Komfortmerkmal ist, das argumentativ für eine bestimmte Untergruppe von Benutzern gilt. Es ist definitiv eine niedrige Priorität, selbst wenn man sich einig ist, dass es nützlich wäre.

[tmomas]

@oshyan

Ich möchte einfach nur in der Lage sein, inline zu suchen und zu verlinken!

Etwas Ähnliches existiert bereits, wenn man Beiträge auswählt und in ein neues/bestehendes Thema verschiebt. Um ehrlich zu sein, ist es in seiner aktuellen Form eine echte Plage:

• Die Suche dauert sehr lange
• Selbst wenn man den Titel des Themas kennt und genau so eingibt, wie er geschrieben ist (richtige Groß-/Kleinschreibung usw.), findet die Suche das gewünschte Thema nicht
• Die Suche findet es, man wählt es aus, und dann läuft die Suche weiter, bevor man überhaupt die Möglichkeit hat, die Auswahl zu bestätigen. Die Auswahl ist weg, die Suche listet das ausgewählte Thema nicht einmal mehr auf

@oshyan

Das würde es super schnell und einfach machen, Links zwischen Themen zu erstellen

Meine Erfahrung ist genau das Gegenteil davon, siehe oben.
Ich bin schneller dabei, das richtige Thema zu finden, wenn ich die Standard-Suchfunktion verwende.

[Don]

Hallo Oshyan,

Die Idee gefällt mir sehr gut, aber…

Da der Titel eines Themas nicht eindeutig ist, erhältst du jetzt bei der Suche nach einem Thema zusätzliche Informationen wie Tags und Kategorien, um es besser zu erkennen. Allerdings könnte eine Inline-Lösung zu überladen wirken, und manchmal gibt es zu viele Treffer für deine Suche, um sie inline zu filtern.

Ein weiterer Punkt:
Wenn du dieses Panel verwendest, um einen Link einzufügen, musst du deine Auswahl durch einen Klick auf eine Bestätigungstaste bestätigen – was meiner Meinung nach sehr nützlich ist.

Bei einer Inline-Lösung musst du, falls du das richtige Thema verpasst, viel zurücknehmen, und es könnten mehr fehlerhaft formatierte Links entstehen als bisher.

Vielleicht gibt es eine gute Möglichkeit, es einfach und schnell zu gestalten, aber aktuell halte ich die Panel-Lösung für schneller und benutzerfreundlicher.

[oshyan (Oshyan Greene)]

@tmomas

Meine Erfahrung ist genau das Gegenteil davon, siehe oben.
Ich bin schneller dabei, das richtige Thema zu finden, wenn ich die Standard-Suchfunktion verwende.

Das alles klingt nach einem Versagen der UI/UX oder der Suchfunktionen, nicht nach einem Problem mit der Idee des Inline-Linkens an sich. Falls du es noch nicht getan hast, schlage ich vor, ein Thema zu eröffnen, um Verbesserungen/Fixes für das bestehende Verhalten von „Beiträge verschieben/zusammenführen

[Don]

Ah ok, ich verstehe, danke für die Klarstellung!
Das wäre ein erweitertes Feature, das das ursprüngliche Suchfeld beibehält.
Klingt für mich nach einer guten Idee.

[sam (Sam Saffron)]

Nur zur Klarstellung: Was wir heute haben, ist:

STRGALTf
Suche nach einem Begriff
NACH UNTEN
a

Zum Beispiel: In-line topic search-and-linking, e.g. Roam-like bracket links

Das Problem ist, dass dies extrem schwer zu vermitteln ist, aber (möglicherweise) einen größeren Funktionsumfang bietet als der Vorschlag mit [[.

[oshyan (Oshyan Greene)]

Oh, das ist sehr interessant und gut zu wissen! Allerdings denke ich, dass es einen wertvollen Unterschied zwischen Aktionen aus der Inline-Syntax und Aktionen über Tastaturbefehle gibt. Die Auffindbarkeit ist ein Punkt, die Geschwindigkeit ein weiterer.

Es stimmt, dass man diese Sequenz, sobald man sie gelernt hat, ziemlich schnell verwenden kann. Aber nachdem ich es ein paar Mal ausprobiert habe, um es zu testen, fühlt es sich definitiv langsamer und weniger flüssig an als meine Erfahrung mit den (immer mehr werdenden) Apps, die [] Klammer-Links unterstützen. Vielleicht liegt das teilweise daran, dass neben dem neuen und etwas ungewohnten Tastaturkürzel auch ein Wechsel der Aufmerksamkeit bzw. des Blicks erforderlich ist. Letzteres mag sich mit der Zeit teilweise ausgleichen lassen (obwohl meine grundlegende Handgeometrie hier gewisse Grenzen setzt), doch der Wechsel der Aufmerksamkeit wird beim Verfassen einer Nachricht immer Kosten verursachen.

Es ist für mich tatsächlich interessant, dass du genug Bedürfnis nach schnellem Verlinken hattest, um diese etwas ungewöhnliche Tastaturkürzel-Sequenz zu erstellen (zweifellos, weil viele andere bereits verwendet wurden). Das deutet für mich ein wenig darauf hin, dass du vielleicht auch einen gewissen Wert in der Idee des Inline-Linkens allgemein siehst… Aber ich habe den Eindruck, dass es derzeit nicht viel Unterstützung für meinen Vorschlag gibt. Trotzdem bin ich neugierig zu wissen, ob es dafür klare Hindernisse gibt, z. B. „Wir verwenden Klammern für etwas anderes“, „wir können keinen weiteren Inline-Handler hinzufügen, da dies alle Datenbankabfragen um 30 % verlangsamen würde“ oder ähnliches.

Wie auch immer, ich hoffe, das hat zumindest jemandes Interesse geweckt. Ich würde es nach wie vor gerne zur Verfügung haben, und ich stelle mir vor, dass andere Nutzer, sobald sie es ausprobieren konnten, es ebenfalls lieben würden (gibt es hier überhaupt Roam-Nutzer? Obsidian? Logseq?). Aber zumindest hoffe ich, dass ich das Interesse an der Idee des Inline-Suchens und -Verlinkens geweckt habe, und vielleicht wird sich in Zukunft etwas darum herum kristallisieren.

[sam (Sam Saffron)]

@oshyan

Trotzdem bin ich neugierig zu wissen, ob es zumindest klare Hindernisse gibt, z. B. „Wir verwenden Klammern für etwas anderes“, „wir können keinen weiteren Inline-Handler hinzufügen, da dies alle Datenbankabfragen um 30 % verlangsamen würde“ oder so ähnlich.

Ich sehe, dass [[ magic search in einer Theme-Komponente heute umsetzbar ist.

Die einzige Einschränkung ist, dass die Vervollständigung [[ entfernen und durch einen Link ersetzen würde; ich bin mir nicht sicher, wie dies sonst funktionieren könnte. Das macht ]] jedoch etwas sinnlos.

Denken Sie daran, dass das Offenhalten der Autovervollständigung über eine Leerzeichen-Grenze hinaus etwas verwirrend sein kann.

[oshyan (Oshyan Greene)]

Das ist gut zu wissen! Als Nicht-Programmierer weiß ich nicht genau, wie viel in Theme-Komponenten möglich ist (viele scheinen es zu sein, was eine der vielen Dinge ist, die ich an Discourse liebe). Das ist also ziemlich cool.

Es stimmt, dass in anderer Software die [[-Syntax beibehalten wird und auch nach dem Hinzufügen eines Links noch einen gewissen Wert behält. Oder besser gesagt: Die [[-Suche füllt keinen herkömmlichen Link automatisch aus, sondern eine spezialisierte interne Referenz. Da mehrere Anwendungen dieses Referenzformat unterstützen, ist es in einer Variante von Markdown portierbar, was sehr praktisch ist.

Aber wie auch immer: Im Fall von Discourse ist [[ nur eine vertraute Inline-Abkürzung, die zum Glück unwahrscheinlich versehentlich ausgelöst wird. Ich wäre mit jeder anderen textbasierten Methode zufrieden, um eine Inline-Suche aufzurufen, die ähnliche Kriterien erfüllt. Trotz der Unterschiede in der Funktionsweise zwischen Discourse und z. B. Roam sehe ich jedoch einen gewissen Vorteil darin, zumindest die Syntax gleich zu halten. Wie gesagt, es entwickelt sich zu einem de-facto-Standard.

Ein weiterer Gedanke, der mir kommt, ist, dass Discourse bereits sein eigenes Äquivalent zu internen Links hat, die auf besondere Weise gerendert werden: So funktioniert das Zitieren! „post:10, topic:200454

[sam (Sam Saffron)]

Ich habe Roam gerade einmal auf den Prüfstand gestellt.

@codinghorror hat in der Vergangenheit mehrmals erwähnt, wie besorgt er darüber ist, wie ineffektiv eine Inline-Suche sein kann, wenn man den Composer verwendet. Allerdings könnte sie im Kontext von Dokumentation und spezifischen Kategorien, in denen der Geltungsbereich enger gefasst ist, nützlich sein.

Wir haben in der Vergangenheit über die Einführung einer Syntax wie #784 diskutiert, die dieser Diskussion sehr ähnlich klingt.

So funktioniert Roam:

1. Du tippst [[
2. Es fügt automatisch ]] hinzu und setzt den Cursor dazwischen.
3. Während du innerhalb von [[ ]] tippst, wird eine autovervollständigende Suche durchgeführt. Zum Beispiel:

4. Wenn du dich schließlich für einen Link entscheidest, wird der vollständige Titel verwendet, z. B. [[13. August 2021]].

5. Es übernimmt Umbenennungen des Originaldokuments automatisch und aktualisiert die Markup-Links in verknüpften Dokumenten.

Etwas Ähnliches wie dieses Verhalten würde ein recht umfangreiches Plugin für Discourse erfordern, das an Stellen eingreift, an denen Themen umbenannt werden, an der Markdown-Engine und mehr. Ich würde das in die Kategorie „mehrere Wochen komplexe Arbeit

[justin (Justin DiRose)]

Für eine interessante Implementierung, die du dir ansehen solltest, empfehle ich https://obsidian.md. Sie verwenden diese Syntax in Markdown-Dateien, und sie scheint der von @sam beschriebenen Spezifikation ähnlich zu sein.

[oshyan (Oshyan Greene)]

OK, also hier fängt es an, dass mein Beispiel mit Roam, wenn man es zu wörtlich nimmt, ins Stocken gerät. Ich habe Roam vor einiger Zeit tatsächlich nicht mehr genutzt, unter anderem weil die Inline-Suche dort völlig unbrauchbar ist. Obsidian ist ein besseres Beispiel und das, was ich jetzt vollzeit nutze, erfordert jedoch einen Download zum Testen, während Roam (oder Logseq) das nicht tun.

Bevor ich weitermache, danke ich @sam für das große Engagement in Bezug auf diese Idee, die mir bewusst ist, dass sie vielleicht etwas aus heiterem Himmel kommt. Und besonders dafür, dass du mir eine grobe Schätzung der Arbeit gegeben hast, die du dafür benötigst, zumindest in der Art, wie du es skizziert hast.

Trotzdem möchte ich betonen, dass meine Anregung von Roam und ähnlichen Apps inspiriert ist, die diese Syntax verwenden, aber ich bin nicht daran interessiert, alles, wie es funktioniert, vollständig zu replizieren.

• Die Klammer muss nicht automatisch vervollständigt werden, da sie im resultierenden Markdown nicht erhalten bleibt (in Roam wird sie behalten, ebenso in Obsidian).
• Die Discourse-Suche, wie sie durch die Link-Suche mit Strg+K oder Strg+Alt+F exemplifiziert wird, ist besser als Roam und würde, wenn sie inline implementiert wäre, wahrscheinlich erlauben, dass ich in einer angemessen kurzen Zeit ein Thema von Interesse finde (d. h. wenn du denkst, dass Suche überhaupt nützlich ist, würde sie das hier beschriebene Bedürfnis bereits so erfüllen).
• Der Link würde den vollständigen Titel verwenden, genau so, als hättest du einen Link zu einem Discourse-Thema in dasselbe Forum in einer Nachricht kopiert/eingefügt.
• Das Umbenennen würde so gehandhabt werden, wie Discourse das bereits für interne Links handhabt.

Also, um zusammenzufassen: Roam ist nur ein Beispiel, um das Konzept und einen Teil der Benutzererfahrung zu demonstrieren. Was ich wirklich vorschlage, ist:

• Eine Reihe von unüblichen, aber schnell getippten Zeichen, die eine Inline-Themensuche auslösen können.
• Inline-Themensuche mit Enter, um das erste Ergebnis automatisch auszuwählen.
• Normales Discourse-Link-Handling in allen anderen Aspekten.
• Implementierung auf die Weise, die am besten zum Discourse-Ansatz passt.

Der Rest dessen, was ich gesagt habe, sind nur Überlegungen darüber, was am sinnvollsten sein könnte oder mögliche Ansätze für das Problem.

Angesichts all dessen: Ändert das die Schätzung des erforderlichen Aufwands? Wenn nicht, was genau an dieser Feature-Anfrage macht sie so viel komplizierter als z. B. Strg+Alt+F + A? Ich frage, weil das mir helfen könnte zu verstehen, ob ich den Umfang der Anfrage einschränken kann, um die Kosten angemessen zu halten, oder ob es einfach nicht den Aufwand wert ist.

Nochmals vielen Dank!

[j127]

Für mich wird es schwieriger, je weniger Discourse mit normalem Markdown kompatibel ist, insbesondere bei der Verschiebung von Inhalten zwischen Discourse und anderen Systemen, die Markdown verwenden. (Meine Websites und Dokumentationen verwenden in der Regel Markdown oder MDX.)

Wenn eine solche Funktion hinzugefügt wird, wäre eine alternative Umsetzungsidee die Verwendung eines Systems ähnlich wie bei Confluence oder Notion, bei dem das Zeichen / (Schrägstrich) ein Menü öffnet.

Hier ist Confluence:

Hier ist Notion:

Wenn eine ähnliche Funktion in Discourse vorhanden wäre, könnte ein Schrägstrich ein Menü öffnen, das „Link

[sam (Sam Saffron)]

@oshyan

Ändert das angesichts all dessen die Schätzung des erforderlichen Aufwands?

Wenn Sie die Dinge innerhalb der bestehenden Strukturen halten, kann eine Theme-Komponente völlig gut funktionieren, und der Aufwand ist nicht enorm. Die [[ ist implementierungstechnisch sogar praktisch, da sie Ihnen einen guten Ankerpunkt gibt, wo Sie mit der Autovervollständigung aufhören sollen.

Ein vollständiges Workflow-Beispiel könnte so aussehen:

1. Benutzer tippt: [[
2. Der Editor füllt ]] aus, der Cursor befindet sich zwischen den Klammern.
3. Benutzer tippt einen Suchbegriff ein, z. B. [[in-line topic]].
4. Während der Benutzer tippt, wird die Suche durchgeführt und die Ergebnisse werden in einer Autovervollständigung ähnlich wie bei @Erwähnungen angezeigt.
5. Mit den Pfeiltasten nach oben/unten oder Enter auswählen.
6. Nach der Auswahl wird [[in-line topic]] durch https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454 ersetzt.
7. Wenn der Benutzer den Cursor einfach über ]] hinaus bewegt, schließt sich die Autovervollständigung und [[in-line topic]] bleibt einfach im Markdown stehen.

Insgesamt ist die Entwicklung eines solchen Systems in einer Theme-Komponente absolut machbar, erfordert keine Änderungen auf der Serverseite und wäre ziemlich einfach umzusetzen. Ich würde sagen, ein Experte könnte innerhalb eines oder zweier Tage etwas daraus machen, während es für jemanden mit mittlerem Erfahrungslevel wahrscheinlich etwa eine Woche dauern würde.

[oshyan (Oshyan Greene)]

@j127

Wenn eine solche Funktion hinzugefügt wird, wäre eine alternative Idee zur Implementierung die Verwendung eines Systems ähnlich wie Confluence oder Notion, bei dem das Zeichen / (Schrägstrich) ein Menü öffnet.

Ja, Slash-Menüs sind definitiv ein interessanter und cooler Ansatz, den ich mag und in vielen Apps verwende. Ich denke, mir ist dieser Weg zur Umsetzung dessen, was ich in diesem Fall wollte, nicht eingefallen, weil dieser Ansatz eine ganze Reihe von Funktionen impliziert, die aufgerufen werden müssen. Mit anderen Worten: Ich finde es würde für Nutzer, die an Slash-Menüs gewöhnt sind, seltsam oder unerwartet wirken, wenn man damit nur eine Linksuche auslöst. Und obwohl es eine ganze Reihe anderer Funktionen im /-Menü geben könnte, was ich definitiv befürworte, klingt das nach einer deutlich umfangreicheren Funktionsanfrage.

@sam

Insgesamt ist die Entwicklung eines solchen Systems in einer Theme-Komponente absolut machbar, erfordert keine Änderungen auf der Serverseite und wäre recht einfach umzusetzen. Ich würde sagen, ein Experte könnte etwas in ein oder zwei Tagen fertigstellen, ein fortgeschrittener Entwickler würde wahrscheinlich etwa eine Woche brauchen.

Fantastisch, danke, dass du dir das durchgedacht und mir einen Eindruck von der Komplexität und der Entwicklungszeit gegeben hast! Das ist extrem hilfreich. Ich muss mir überlegen, ob ich etwas eigenes Geld dafür einsetzen kann, da ich noch einige andere, vielleicht wichtigere Anfragen habe, die ich wahrscheinlich für die Entwicklung finanzieren muss. Und jetzt, da ich mehr über die Tastenkürzel weiß, ist diese Funktion eher eine Bequemlichkeit als eine Notwendigkeit.

[thoka (Thomas Kalka)]

Das wäre noch interessanter, wenn „einen benannten Link erstellen“ beim Hinzufügen des Links über a zu ausgewähltem Text unterstützt würde. Ich würde diese Aktion gerne in [ausgewählter Text](Link) umwandeln.

Leider scheint sie sich nicht in den Rückgängig-Puffer einzufügen.

[almereyda (jon r)]

Andere gute Beispiele für / und [[ ]] Tipp- (Arbeits-) Flows, von denen man sich inspirieren lassen kann, werden gegeben von

Outline – Team knowledge base & wiki

und

logseq.github.io

[seong (Seong-Young Her)]

Dieses Konzept eines persönlichen Wissensmanagementsystems + Forums ist wirklich zukunftsorientiert und potenziell sehr leistungsfähig. Es ist nicht „neu“ (z. B. siehe „Bliki“ von 2003), aber das muss es auch nicht sein. Der Kontext ist neu und daher auch die Idee. Der PKM-Markt wächst sehr schnell, weil jeder etwas Ähnliches wie das, was Sie beschreiben, möchte, aber es existiert nicht. Dennoch glaube ich nicht, dass Wikilinks die richtige Lösung wären; „Link zum Hervorheben“-Funktionen, die in Discourse integriert sind (als Verbesserung/Variante der aktuellen Zitatfunktionalität), wären es. Die Schaltfläche „Teilen“, die erscheint, wenn Sie Text in einem Beitrag hervorheben, sollte eine URL sowie eine Option zum Erstellen eines neuen Themas im Forum unter Verwendung des Zitats bereitstellen (letztere Funktion ist drei Klicks entfernt und funktioniert nicht ganz richtig). Aber ich kann sehen, wie nützlich es sein könnte, Wikilinks zu Themen zu erstellen, die noch nicht existieren, welche dann zu Wiki-Posts werden, sobald jemand darauf klickt und sie erstellt.

Ich denke, Ihr Garden ist ein großartiger Proof of Concept und weitgehend durch die Tatsache eingeschränkt, dass er aus Discourse zusammengebastelt wurde (glauben Sie, dass er als Wiki, Zettelkasten oder Circle/Notion-Instanz besser funktionieren würde?). Ein gemeinsames PKM kann leicht auseinanderfallen, wenn die Qualität der Beiträge nicht streng kontrolliert wird: tiefe, aber nutzlose Inhalte können sich verfestigen, ohne dass es eine Möglichkeit gibt, die Qualität der Inhalte zu beurteilen, bevor man darauf klickt. Foren bewältigen die offene kollaborative Wissensproduktion viel besser als herkömmliche PKMs. Hier ist ein interessantes Zwischenbeispiel: LessWrong hat ein „Community-Blog“-System, das tatsächlich ein Reddit-Fork ist, und es funktioniert für ihre Zwecke brillant. Es ermöglicht ihnen, die Herausforderung zu umgehen, dass alle Mitwirkenden von Anfang an gut in dem sein müssen, was sie tun; Benutzerbeiträge (Posts und Playlist-ähnliche Sammlungen von Posts) sind nicht kanonisch (im Gegensatz dazu, dass es auf einem Wiki normalerweise nur einen Artikel pro Thema gibt).

[oshyan (Oshyan Greene)]

@seong

Ich halte Ihr Garden für ein großartiges Proof of Concept, das größtenteils durch die Zusammenstückelung aus Discourse eingeschränkt ist (glauben Sie, dass es als Wiki, Zettelkasten oder Circle/Notion-Instanz besser funktionieren würde?)

Manches wäre besser, manches merklich schlechter. Ich bin in einigen wichtigen Punkten für meine Zwecke definitiv durch Discourse eingeschränkt, aber ich denke, einer der Hauptpunkte ist einfach die Navigation, die halbwegs einfach zu beheben zu sein scheint, wenn der Wille und damit die Entwicklungsressourcen vorhanden sind. Ich habe eine Idee, die ich bald vorschlagen werde (mit etwas Finanzierung), von der ich hoffe, dass sie helfen wird.

Ich denke auch, dass es wertvoll ist, über die Idee nachzudenken, das Konzept des Moderators in bestimmten Wissensgenerierungskontexten zu erweitern, um eher einem „Kurator“ zu ähneln. Die Solo-Wissensgenerierung kombiniert Generator- und Kuratorrollen/-aktivitäten. Aber die kollektive Wissensgenerierung erfordert wahrscheinlich – oder profitiert zumindest erheblich von – vertrauenswürdigen Personen, deren Rolle oder Teil ihres Fokus darin besteht, Inhalte, Ideen usw. zu zitieren, zu fördern, zu organisieren, zu polieren und anderweitig hervorzuheben, die andere generieren, und sie für diejenigen zugänglicher zu machen, die davon profitieren könnten. Theoretisch könnte die Wiki-Funktionalität in Discourse Teil der Lösung sein, aber sie müsste einige Anpassungen erfahren.

Es gibt auch viele interessante Dinge zu bedenken in Bezug auf kollaborative Wissensgenerierung, „digitales Gärtnern“ usw. Ist das Ziel, einzelne Dokumente zu erhalten, die eine kollektive Perspektive und ein kollektives Verständnis darstellen? Oder um mehrere Perspektiven gleichzeitig darzustellen? Oder eine Kombination aus beidem. Ich kann viele mögliche Ansätze sehen, diese und andere Fragen zu behandeln.

Letztendlich ist die Herausforderung, dass CDCK sich wahrscheinlich nicht für diese Verwendungen von Discourse interessiert (was ich verstehen kann, da ihr Nutzen und damit ihr Umsatzpotenzial zu diesem Zeitpunkt viel jünger und unklarer sind). Und in der Zwischenzeit adressieren nur wenige – wenn überhaupt – andere Plattformen, die sich auf Wissensgenerierung konzentrieren, z. B. Wikipedia/MediaWiki, die konversationellen, diskursiven Aspekte gut genug, und insbesondere die Interaktion zwischen beidem. In einer perfekten Welt könnte qualitativ hochwertiger Diskurs über lange Zeiträume inkrementell zu einem destillierten Ergebnis von Wissen, Ideen, Perspektiven beitragen, leicht und flüssig, wobei die Namensnennung beibehalten wird und gleichzeitig gut formatierte, konsistente „Dokumente“/Artefakte ermöglicht werden, die tatsächlich angenehm zu lesen wären. Wikipedia ist wieder ein gutes Beispiel für das aktuelle Modell, das funktioniert, aber es ist sehr unvollkommen und neuere Werkzeuge und Methoden sind erforderlich, um über die reine Dokumentation von Wissen hinauszugehen und tatsächlich Erkenntnisse zu generieren, neue Ideen zu erforschen usw.

Discourse kann jetzt für diese Dinge verwendet werden, in mancher Hinsicht einfacher als in anderen. Aber es kann getan werden, es hat das meiste, was benötigt wird…