Ich kann zwei Dinge nicht herausfinden:
Hat jemand anderes dieses Problem schon erlebt?
Es ist möglich, aber wir haben einen Sonderfall, der es komplizierter macht als ein einfaches Drop-in. Der Kategorienselektor erlaubt nur das Hinzufügen bestehender Kategorien… aber wir erlauben derzeit einen benutzerdefinierten @-Eintrag, um die Komponente auf die oberste Ansicht “alle Kategorien” anzuwenden.
Wir müssen das in eine separate Einstellung aufteilen und die bestehenden Einstellungen migrieren, um die Kategorien-Dropdown-Liste verwenden zu können.
Dieser Tab?
Ich kann das Problem nicht reproduzieren, es wurde möglicherweise bereits behoben – wenn Sie es immer noch erleben, lassen Sie es uns wissen.
[Zitat=“awesomerobot, Beitrag:3, Thema:366791”]
Ich kann das Problem nicht reproduzieren, es wurde möglicherweise bereits behoben — wenn Sie es weiterhin haben, lassen Sie es uns wissen.
[/Zitat]
Entschuldigung, ich habe Discourse inzwischen verlassen und meine Community wieder zu Discord verlegt.
[Zitat=“awesomerobot, Beitrag:3, Thema:366791”]
Der Kategoriewähler erlaubt nur das Hinzufügen vorhandener Kategorien… aber wir erlauben derzeit, einen benutzerdefinierten @-Eintrag hinzuzufügen, um die Komponente auf die Ansicht “Alle Kategorien” auf der obersten Ebene anzuwenden.
[/Zitat]
Das ist unglaublich verwirrend. Könnten Sie erklären, was das “@” bedeutet und wie man es benutzt? Ich habe es in der Kanban-Einstellungs-UI gesehen und konnte nicht herausfinden, was es bewirkt.
Außerdem, warum macht es das Hinzufügen eines benutzerdefinierten “@” unmöglich, das Dropdown zu verwenden? Einfach den “@”-Eintrag zum Dropdown hinzufügen, würde das nicht funktionieren? Und noch besser, warum nennt man es “@”? Stattdessen könnte man “Alle Kategorien” in diesem Dropdown sagen und es im Hintergrund das “@” verwenden. Es hat sich als zu kryptisch erwiesen, sogar für mich, einen Softwareentwickler, der Discourse seit Anfängen benutzt.
Das ist offensichtlich nicht zum Thema, aber ich möchte meinen Senf dazugeben und sagen, dass die anhaltenden Frustrationen mit der Discourse-Benutzeroberfläche dazu führen, dass es mir völlig misslingt, meine Partner und Projektbeteiligten für die Nutzung von Discourse zu gewinnen. Sie alle hassen die Benutzeroberfläche, sie können sie einfach nicht benutzen, weil sie in jeder Hinsicht verwirrend ist, und diese Unfähigkeit, Kanban zu einem nützlichen Werkzeug zu machen, trägt nur zur Frustration der Partner bei, die ich davon überzeugen möchte, sich für die Nutzung von Discourse für das Projektmanagement zu entscheiden. Um auf das eigentliche Thema dieses Threads zurückzukommen: Wie zum Teufel soll ich das “@” einem Manager erklären, der einfach nur das Einstellungsfenster öffnen und die Kanban-Listen nach Belieben konfigurieren möchte? Es sind all diese Kleinigkeiten, die sich summieren und die Leute völlig desorientieren, wenn sie den Discourse-Bereich betreten, und sie versuchen, ihn sofort wieder zu verlassen und mich zu bitten, sie auf dieser Plattform nicht mehr anzusprechen, da dies ihre Zeit verschwendet. Ich bin hilflos, wenn es darum geht, die Leute für Discourse zu begeistern. Und schlimmer noch, aus irgendeinem Grund verschlimmert das Discourse-Team einige Aspekte der Benutzeroberfläche, anstatt sie zu verbessern. Sehen Sie hier eine aktuelle Aktualisierung und meine Kritik daran: Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
Übrigens, wenn ich dort @MyCategory eingebe (was ich intuitiv getan habe, als ich versucht habe zu verstehen, was das “@” tut), werden mir keine Validierungsfehler angezeigt. Wie kann es als in Ordnung angesehen werden, mir nicht mitzuteilen, dass ich etwas falsch mache, wenn es aus der Sicht des Programmierers offensichtlich ist und leicht erkannt werden kann, wenn der aktualisierte Einstellungswert “Speichern…” wird.
Entschuldigung, dass ich das alles sagen musste, besonders nachdem ich gesehen habe, dass jemand Discourse verlassen und zu Discord zurückgekehrt ist, was meine Bedenken und Frustrationen mit der Benutzeroberfläche nur bestätigt hat.
Ich habe mich wirklich angestrengt, aber es gibt einfach zu viel Komplexität. Es ist wie in alten Zeiten – Android- vs. iPhone-Kriege.
Android erlaubte dir, alles anzupassen, was du wolltest.
iPhone war super begrenzt, aber… funktionierte einfach.
Das Gleiche gilt derzeit für Discourse. Ich glaube, wir müssen mehr den Weg von Antoine de Saint-Exupéry gehen: „Vollkommenheit entsteht nicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn es nichts mehr wegzunehmen gibt.“
Es gibt so viel Verwirrung (wie DMs vs. private Chats, um das erste zu nennen, das mir einfällt), dass es wirklich schwer ist, Leute davon zu überzeugen, es freiwillig zu nutzen. Auf Discord gibt es weniger Hürden. Dasselbe gilt für Skool. Ich denke, das ist es, was wir anstreben sollten, nicht das Hinzufügen weiterer Funktionen.
Ich hatte kürzlich einen Kunden, der Discourse genau aus dem Grund verlassen hat – wegen der Komplexität.
Aber ehrlich gesagt, wenn ich mir einige Discord-Server anschaue, würde ich nicht sagen, dass sie wirklich einfach sind? Es gibt heute viele Dinge, die man zu einem Discord-Server hinzufügen kann (einschließlich Bots).
Ein großer Nachteil eines Wechsels zu Discord oder einer anderen maßgeschneiderten geschlossenen App ist, dass man keine SEO-Vorteile mehr hat, oder? Vielleicht betrifft dich das nicht.
Wer auch immer es implementiert hat, wählte @ als eindeutiges Symbol, um die Top-Level-Topic-Listen darzustellen, wenn sie nicht nach Kategorie oder Tag gefiltert sind. Dies ist wie forum.example.com/latest oder forum.example.com/top. Sie geben also @ separat als eigenen Eintrag ein, um das Board dort anzuwenden.
Ich stimme zu, dass dies verwirrend ist, aber es ist etwas, das ignoriert werden kann, es sei denn, Sie möchten globale Kanban-Boards.
Das ist nicht der Fall, es erschwert nur den Wechsel zum Kategorie-Dropdown, da wir auch eine Migration erstellen müssen, damit wir die Einstellungen auf Websites, die es bereits auf diese Weise verwenden, nicht zurücksetzen.
Theme-Einstellungen werden von Core-APIs bestimmt, daher können wir sie, wenn wir den Listentyp Kategorie verwenden, nicht mit zusätzlichen Optionen aus dem Theme selbst erweitern.
Discourse ist kein riesiges Unternehmen, wir haben Zeitbeschränkungen, um uns auf die am häufigsten genutzten Funktionen zu konzentrieren, und die Refaktorierung von Komponenten (die übrigens kostenlos angeboten werden) kann schwierig zu priorisieren sein. Wenn jemand Verbesserungen an den Kanban-Einstellungen sponsern möchte, können wir dies sicherlich zu einer höheren Priorität machen.
Gibt es bei Discord eine Kanban-Board-Funktion? Ich habe nachgesehen, aber abgesehen von einem Bot, der sich in einen externen Kanban-Dienst integriert, habe ich nicht viel gefunden.
Sie verlieren auch etwas Kontrolle, Ihre Benutzer sind Discord-Benutzer, die Inhalte, die sie posten, sind ebenfalls Discord-Inhalte. Wenn jemand für Discord bezahlt, ist der Gewinn für Discord. Jede Plattform hat ihre Vor- und Nachteile und Kosten.
Ja, es ist unklar, wann wir in der Lage sein werden, uns auf die Kanban-Funktion zu konzentrieren.
Es ist etwas, das ich zu einem bestimmten Zeitpunkt wieder aufgreifen möchte. Ich denke, die Einführung der Theme-Komponente hat einige Beweise dafür geliefert, dass es eine Nachfrage nach mehr dieser Art von Dingen gibt.
Die Implementierung als Theme-Komponente hatte Vorteile – es ist für jeden Administrator relativ einfach, sie zu finden und zu installieren –, aber sie bringt auch einige erhebliche Einschränkungen mit sich, die es schwierig machen, sie so zu gestalten, wie man es erwarten würde.
Wenn und wann wir uns damit wieder befassen, denke ich, dass es zwei mögliche Wege gibt – wir könnten den gewünschten Funktionsumfang für ein Kanban-Board als Grund nehmen, um die für Theme-Komponenten verfügbaren APIs zu verbessern, oder wir könnten es zu einer Kernfunktion oder einem Plugin machen und mehr Zugriff auf die passenden serverseitigen APIs haben, die wir benötigen.
Bis dahin wird es wahrscheinlich nur kleinere Anpassungen für spezifische Probleme geben.
Das stimmt, aber diese Last liegt bei uns – den Besitzern – nicht bei den Benutzern. Benutzer sehen es auf die denkbar einfachste Weise:
Kanal auswählen → Nachricht senden und das war’s!
Es gibt kein Kanban. Es ist nicht notwendig, den Unterschied zwischen Beobachten und Verfolgen zu verstehen. Es gibt keine ganze Menge von Hey-wie-cool-wäre-es-wenn-Discourse-AUCH-dieses-und-jenes-könnte-Funktionen.
All diese Funktionen sind super cool, für uns – technische Leute/Besitzer/Admins.
Aber für normale Leute – sie wollen ein Gemeinschaftsgefühl. Sie wollen das Gefühl haben, dass sie sich frei ausdrücken können und nicht all diese Hunderte (ich glaube, es gibt so viele) verschiedenen Optionen, Begriffe und anderes Zeug herausfinden müssen.
Das ist genau das Feedback, das ich von den Stakeholdern erhalte. Sie verlieren sich in Chats vs. privaten Themen.
In meinem aktuellen Projekt prüft der Projekteigentümer Basecamp, weil er sagt, er könne Discourse nach dem Ausprobieren einfach nicht nutzen. Ich setze mich für Discourse ein, weil ich seine herausragenden Funktionen und Fähigkeiten kenne, aber ich kann nicht viel tun, weil die schlechte Benutzerfreundlichkeit und ein Durcheinander sowohl in der Benutzeroberfläche als auch in der Terminologie immer die Funktionalität überwiegen. Ganz zu schweigen von Markdown, das jeder normale, nicht-technische Mensch hasst, und ich kann ihnen nicht erklären, warum es überhaupt kein WYSIWYG ist. Gott sei Dank arbeitet das Discourse-Team endlich am richtigen Editor. Die meisten Leute wollen einen einfachen, wortähnlichen Texteditor mit nur wenigen Funktionen: Formatierung, Tabellen, Farben, Bilder, Code-Snippets. Es gibt keinen Grund, warum eines davon von einem normalen Benutzer in Form von Markdown bezogen werden sollte. Anspruchsvollere Funktionen wie KI scheinen nutzlos zu sein, wenn der Endbenutzer nicht herausfinden kann, warum sein Beitrags-Texteditor vertikal in zwei Spalten unterteilt ist – das ist es, worüber sie nachdenken, nicht über KI.
Sie haben alle Daten. Das ist der Deal, und ich verstehe die anfängliche Frustration, aber ich sehe in den letzten Monaten viele Verbesserungen bei Discourse.
Administratoren können wählen, ob sie Chats und/oder private Nachrichten nicht mehr nutzen und vereinfachen möchten. Es braucht Zeit und es gibt eine Lernkurve, die sicher jeder versteht. Vor- und Nachteile wie bei allem.
Ich wünsche dem Team das Beste und denke, wir müssen wirklich beitragen und dem natürlichen Evolutionsprozess Zeit geben.
Das ist kurzfristig in Ordnung, aber keine gute Dynamik für die Organisation von Informationen?
Benutzer schießen aus der Hüfte \u003c\u003e eine gut organisierte Website.
Daher der Fokus von Discourse auf Moderation und Werkzeuge zur Organisation von Dingen?
Dies ist genau der Fall, in dem wir mit der sich ändernden Landschaft, wie die Mitglieder unserer Communities Inhalte konsumieren, nicht Schritt halten.
Ich stand vor genau derselben Entscheidung. Etwas Robustes, gut Organisiertes, mit großartiger SEO, etwas, das es uns ermöglichen wird, ein Vermächtnis zu schaffen, aufgrund der Art der Inhalte, die wir erstellen.
Aber die Leute heute (und das ist offensichtlich eine Verallgemeinerung) haben nicht das Gefühl, dass z. B. Slack etwas wegnimmt, indem es den Verlauf auf die letzten 90 Tage beschränkt.
Eines meiner Mitglieder sagte mir (und sie ist eine äußerst erfolgreiche Unternehmerin, die gerade 30 geworden ist), dass sie heute, wenn die Informationen älter als 3 Monate sind, sie nicht mehr liest, da sich alles so schnell ändert und das Ausgraben von alten Dingen nur Zeitverschwendung ist. Unabhängig davon, ob es sich um Wirtschaft, Wissenschaft oder… nun ja, das Leben handelt.
Und natürlich ist es bei Threads wie diesen, die sich auf Plugins beziehen, die möglicherweise viele Monate später aktualisiert werden - ein valider Fall. Aber abgesehen davon geht es im Sinne des “Aufbaus der Community” mehr um das “Zugehörigkeitsgefühl” und die Möglichkeit, mit dieser Community mit wenig bis gar keiner Reibung zu interagieren, anstatt all die überwältigenden Optionen herauszufinden.
Ich habe in früheren Threads darüber gesprochen, wo ich nach dem Erfolg von Skool im Vergleich zu Discourse gefragt habe.
[Zitat=“ludwikc, Beitrag:20, Thema:366791”]
es geht mehr um das „Gefühl der Zugehörigkeit“ und die Fähigkeit, mit dieser Gemeinschaft mit wenig bis keinem Reibungsverlust zu interagieren, anstatt alle Optionen zu erkunden, die uns überwältigen.
[/Zitat]
Ich verstehe das vollkommen, danke für deinen Einblick.
Um ganz klar zu sein – ich sehe ein erstaunliches Potenzial in Discourse, und wenn ich jemals dazu beitragen kann, dem Team mit meiner Erfahrung im Community-Aufbau zu helfen – bin ich gerne bereit dazu.
