Wie wäre es mit einem "fortgeschrittenen" oder "geführten" Einreichungsprozess für neue Themen in bestimmten Kategorien

[jordan-violet]

Ich liebe das Tagging in Discourse, und die lockere Struktur ist die meiste Zeit großartig. Für einige Anwendungsfälle wäre es jedoch großartig, eine geführte Einreichung zu haben, die eine bestimmte Reihe von Eingaben garantiert, die das Feld „optionale Tags“ im Standardfenster zur Themen-Erstellung den Benutzern nicht bietet.

Mein Anwendungsfall ist dieser:
In einer Kategorie für Support-Anfragen möchte ich garantieren (nicht nur über eine Vorlage vorschlagen), dass die Leute eine bestimmte Reihe von Tags aus verschiedenen Kategorien verwenden, und sie können sofort alle verfügbaren Optionen sehen, die die Kategorien von Tags erfordern.

Ich stelle mir vor, dass in Kategorien, in denen diese Funktion aktiviert ist, das Klicken auf „Thema erstellen“ zuerst ein Modal öffnet. Das Modal würde die meisten der gleichen Fragen stellen, aber es hätte vordefinierte, erforderliche Tag-Kategorien/Übergeordnete Tags/Tags, wie in den Kategorieeinstellungen definiert.

Ich kann sicherlich zeichnen, was ich in meinem Kopf sehe, wenn jemand eine schreckliche MS Paint-Mockup möchte

[Canapin (Coin-coin le Canapin)]

@Jordan Violet

Wenn jemand einen schrecklichen MS Paint-Mockup will

Wer mag keine schrecklichen Paint-Mockups?

Das wäre nett, da ich deine Anfrage nicht ganz verstehe.

[jordan-violet]

Sicher.

Das Tagging ist heute nur eine große, offene Kiste mit „Vorschlägen“. Wenn jemand eine Supportanfrage in meiner Supportkategorie einreicht, muss ich wissen:

Um welches Produkt geht es bei Ihrer Anfrage? Produkt A oder Produkt B? Ich habe eine Tag-Kategorie „Produkte“ mit zwei Tags darunter:

• produkt-a
• produkt-b

Ich habe auch einige Funktionen, die für alle Produkte gelten, aber ich muss wissen, auf welche Funktion(en) Sie sich bei der Unterstützung beziehen. Funktion A, B, C usw. Ich habe eine Tag-Kategorie „Funktionen“ mit mehreren Tags darunter:

• funktion-a
• funktion-b
• funktion-c
• usw.

---

Wiederum, für die meisten unserer Forenerfahrungen ist eine bunte Mischung von Tags in Ordnung. Für unsere Supportkategorie müssen die Leute jedoch sehr konsistent und sehr spezifisch sein. Es gibt Discourse-Funktionen, die das irgendwie ermöglichen, aber sie sind sehr unklar. Ich kann zum Beispiel eine bestimmte Anzahl von Tags vorschreiben … aber sie könnten Tags aus anderen offenen Tag-Kategorien auswählen. Außerdem, wenn eine Tag-Kategorie zu viele Tags hat, werden nicht alle im Dropdown-Menü angezeigt, sodass sie im Voraus durch mündliche Überlieferung wissen müssen, welche Tags existieren könnten.

Ich schlage etwas wie das hier vor.

1. Der Benutzer klickt auf Neues Thema
2. Ein modales Fenster wird angezeigt, um ein neues Thema zu erstellen
3. Die erforderlichen Tags zur Auswahl basieren auf den erforderlichen Tag-Gruppen für die Kategorie

Ich bin sicher, dass dies im bestehenden Fenster für neue Themen geschehen könnte. Ich bin nur schrecklich darin, Frontends zu entwerfen, um das herauszufinden.

[jordan-violet]

Für jede erforderliche Tag-Gruppe in den Kategorieeinstellungen könnten Sie eine zugehörige Frage haben, die in der Benutzeroberfläche für neue Themen für diese Tag-Gruppe angezeigt wird.

[ondrej]

Hallo Jordan. Vor langer Zeit hatte ich dieses Plugin installiert und soweit ich mich erinnere, kann es Themen ähnlich wie von Ihnen vorgeschlagen erstellen.

Custom Wizard Plugin

Summary Forms for Discourse. This plugin lets you make rich and powerful forms for your Discourse forum. Better user onboarding, structured posting, data enrichment, automated actions and much more for your community. Repository Link https://github.com/paviliondev/discourse-custom-wizard Install Guide How to install plugins in Discourse Community Community based support and discussions about this plugin are hosted on th…

[simon]

@jordan-violet

Um welches Produkt geht es? Produkt A oder Produkt B?

@jordan-violet

Welche Funktion(en) werden unterstützt? Funktion A, B, C usw.

Ich bin mir nicht sicher, ob Sie das bereits wissen, aber Sie können dieses Verhalten mit Tag-Gruppen und Kategorieeinstellungen erzwingen. Die Benutzeroberfläche gibt dem Benutzer einige Hinweise, wie die Tags angewendet werden müssen, aber ich bin mir nicht sicher, wie klar die Benutzeroberfläche für die meisten Benutzer wäre.

Erstellen Sie zuerst Tag-Gruppen für Produkte und Funktionen. Zum Beispiel:

Konfigurieren Sie die Tag-Einstellungen Ihrer Support-Kategorie wie folgt:

Wenn Sie ein neues Thema in der Kategorie erstellen, sehen die Benutzer zuerst Folgendes:

Wenn Sie auf das Tag-Eingabefeld klicken, öffnet sich ein Dropdown-Menü, das es den Benutzern nur erlaubt, eines der Produkte-Tags auszuwählen:

Nachdem ein Produkte-Tag ausgewählt wurde, wird dem Benutzer die Liste der zulässigen Funktionen-Tags angezeigt:

Sie könnten die Funktionen-Tags auch als erforderlich festlegen, indem Sie sie zur Einstellung für erforderliche Tag-Gruppen hinzufügen, die in einem früheren Screenshot hervorgehoben wurde. Die Reihenfolge, in der Tags zur Einstellung für erforderliche Tag-Gruppen der Kategorie hinzugefügt werden, scheint in der Benutzeroberfläche beibehalten zu werden. Ich bin mir nicht sicher, ob das beabsichtigt ist, aber es ist in diesem Fall hilfreich, wenn Sie möchten, dass Benutzer zuerst ein Produkte-Tag und dann ein Funktionen-Tag auswählen:

Möglicherweise verfügt Discourse also bereits über die Funktionalität, nach der Sie suchen, aber die Benutzeroberfläche könnte verbessert werden.

In Bezug auf den obigen Screenshot wird den Benutzern im Dropdown-Menü für Tags der Text „Suchen oder erstellen“ angezeigt, obwohl sie basierend auf den Kategorieeinstellungen nur die Option haben sollten, nach Tags aus der Funktionen-Tag-Gruppe zu suchen. Die Instanz von Discourse, die ich teste, ist nicht ganz aktuell, daher kann ich nicht bestätigen, ob dies ein aktueller Fehler ist. Das kann ich später testen. In jedem Fall wird, wenn ich versuche, das Thema mit einem zusätzlichen Tag zu erstellen, ein Fehler zurückgegeben.

Dies scheint ein Fehler zu sein, aber ich muss meine lokale Discourse-Instanz aktualisieren, um dies zu bestätigen.

Bearbeiten: Ich habe hier ein paar Probleme im Zusammenhang damit erwähnt: Tag "Search or create" text is displayed when a category has restricted tags

[jordan-violet]

Sehen Sie… es ist nah dran. Es ist eine Idee, die definitiv in die richtige Richtung geht, aber sie ist noch nicht ganz da.

Ich habe eine neue Kategorie erstellt, die ein Tag aus unserer Tag-Gruppe „Produkte“ und zwei Tags aus unserer Tag-Gruppe „Erweiterbarkeitsfunktionen“ erfordert:

So sieht das Erstellen eines neuen Beitrags aus. Das Dropdown-Feld für Tags sagt, bevor man darauf klickt, nur „mindestens 3 Tags auswählen…“. Das ist zunächst mehrdeutig und lässt den Benutzer nicht sofort wissen, dass ich einen Tag aus der Produkt-Tag-Gruppe und zwei Tags aus der Erweiterbarkeitsfunktionen-Tag-Gruppe benötige. Aber gut, klicken wir darauf:

Eine genauere Betrachtung zeigt:

• Die ersten 3 Elemente sind „Erweiterbarkeitsfunktionen“
• Die nächsten 2 Elemente sind „Produkte“
• Die letzten 5 sind „Erweiterbarkeitsfunktionen“
• Es gibt immer noch 17 mögliche „Erweiterbarkeitsfunktionen“-Tags, die ihnen nicht bewusst sind.

[jordan-violet]

Hier ist ein einfaches HTML-Formular, das besser veranschaulicht, was der Benutzer sehen sollte (natürlich vor jeglichem tatsächlichen Design):

[simon]

@Jordan Violet

Es ist eine Idee, die definitiv in die richtige Richtung geht, aber sie ist noch nicht ganz ausgereift.

Ich denke, es gibt einen Bedarf an realen Anwendungsfällen, ähnlich wie bei Ihnen, um die Tagging-Benutzeroberfläche zu verbessern.

@Jordan Violet

• Die ersten 3 Elemente sind „Erweiterbarkeitsfunktionen“
• Die nächsten 2 Elemente sind „Produkte“
• Die letzten 5 sind „Erweiterbarkeitsfunktionen“

Das liegt wahrscheinlich daran, dass Sie dies als Mitarbeiterbenutzer testen. Tag-Beschränkungen werden nicht auf Administratoren angewendet (möglicherweise auch nicht auf Moderatoren), daher spiegelt das, was Sie sehen, nicht das wider, was ein normaler Benutzer sehen würde.

Hier ist mein Test mit einem normalen TL3-Benutzer (beachten Sie, dass ich zunächst nur aus products auswählen kann):

Hier ist, was ich sehe, wenn ich dasselbe als Administratorbenutzer teste (Tags aus beiden Tag-Gruppen, alphabetisch sortiert):

Dieser Unterschied kann zu Verwirrung bei der Konfiguration von Tag-Gruppenberechtigungen führen.

@Jordan Violet

Es gibt immer noch 17 mögliche „Erweiterbarkeitsfunktionen“-Tags, von denen sie nicht wissen, dass sie möglich sind.

Ja, das ist ein Problem.

[jordan-violet]

@simon

Das liegt wahrscheinlich daran, dass Sie dies als Mitarbeiter testen.

Ah, das mag der Fall sein – aber ich würde sagen, das ist nur 1/10 des Problems. Ich werde das jetzt ausprobieren, nur um sicherzugehen, dass ich die vollständige Erfahrung gesehen habe.

Ich würde sagen, die Mehrheit des Problems bleibt bestehen.

[BryanV (Bryan Van de ven)]

Es wurden bereits ähnliche Anfragen gestellt, die jedoch keine Resonanz zu finden schienen.

Mandatory onboarding training for code formatting?

Hi, I run https://discourse.bokeh.org and also frequent https://discuss.python.org often. In both places, there is a pretty terrible issue with new users not formatting code in their first posts. There are typically several posts per day on the main Python forum where users need to be corrected. [1] This is huge, constant drain on many people’s time. Would it be possible to have mandatory onboarding flows, before a new users is allowed to make a first post? I am thinking explicitly of a flow wh…