"Private Unterstützung" als Teil einer öffentlichen Support-Community anbieten

[RGJ (Richard - Communiteq)]

Ich habe eine Weile darüber nachgedacht und beschlossen, meine Ideen in die Gruppe zu werfen und euch alle zu fragen, was ihr denkt.

In den letzten Monaten habe ich mit ziemlich vielen Leuten gesprochen, die versuchen, direkten Kundensupport einzurichten – bei dem ein Support-Team (vertrauliche) kundenspezifische Probleme löst – zusätzlich zu ihrem bestehenden (öffentlichen) Community-Support-Forum.
Die meisten dieser Lösungen beinhalten die Plugins ‘assign’, ‘solved’ und ‘ticket’, und dann gibt es mehrere Ansätze (aber es scheint keine Wunderwaffe zu geben, und deshalb erstelle ich dieses Thema).

Lösung Nr. 1: Erstellen Sie separate Kategorien / Gruppen für jeden Kunden

Dies funktioniert nur, wenn Sie eine relativ geringe Anzahl von Kunden haben, nicht wenn Sie Hunderte haben.

Lösung Nr. 2: Die von schungx beschriebene Lösung “How to Use Discourse as a Private Support/Ticket System”

Der Haupt-Störenfried hier ist: “(…) dass Sie eine dedizierte Ticket-Plattform erstellen, oder dass es zumindest keine Überschneidung zwischen den Benutzern Ihrer Discourse-Weboberfläche und denen gibt, die Support-Tickets anfordern.”

Aber dieses Thema befasst sich mit einem der Hauptprobleme: “Sie haben sich das Sicherheits-/Berechtigungssystem angesehen und finden nicht, was Sie wollen: Grundsätzlich gibt es keine reinen Erstellungs- und Erstellungs-/Antwortberechtigungen.” Ich werde unten darauf zurückkommen.

Lösung Nr. 3: Gruppen-Posteingänge.

Sams ursprüngliche Idee “Discourse as a private email support portal”, die zu Gruppen-Posteingängen wurde. Sie richten einen Gruppen-Posteingang ein, weisen ihn Ihrem Support-Team zu, und jeder kann Nachrichten an den Posteingang senden oder per E-Mail senden.
Dies ist jetzt die Go-to-Lösung und sie funktioniert.

Jedoch mag ich sie nicht sehr.

Meiner Meinung nach (!) gibt es eine Reihe von Nachteilen bei diesem Ansatz, und die drei wichtigsten sind:

• Nachrichten, die an die Support-Gruppe gesendet werden, sind schwer zu finden (eigentlich sind meiner Meinung nach alle Nachrichten schwer zu finden, wenn man keine Benachrichtigung zum Anklicken hat) und obwohl das Support-Personal einen guten Überblick hat, hat ein Benutzer keinen. Wo die Mitarbeiter, die an den Tickets arbeiten, einen separaten Gruppen-Posteingang sehen, können Benutzer, die die Tickets erstellt haben, sie nur zwischen ihren ‘normalen’ PMs finden.
• Fehlende Tag-Unterstützung in PMs: Nur Mitarbeiter können PMs taggen, und Benutzer können Tags nicht sehen oder filtern.
• Es gibt keinen “Ort”, an den man gehen und eine Nachricht senden kann. Die Möglichkeit, das Support-Team zu kontaktieren, muss explizit irgendwo beworben werden (und ich finde es schwer, einen logischen Ort dafür zu finden, meistens landet es in irgendeiner Art von Banner).

Alles in allem fühlt es sich für mich ein wenig “angeklebt” und ein Kompromiss zwischen Kategorie-Themen und PMs an.

Nr. 4 Private Themen

Diese Idee wurde bereits mehrfach vorgestellt (auch hier hier und hier), und ich habe bereits oben die Berechtigungen “erstellen” und “erstellen/antworten” erwähnt.

Was wäre, wenn es eine Art “Drop-Box”-Kategorie gäbe, in der Leute ein Thema starten und mit dem Support-Personal (im Grunde: einer Gruppe) interagieren können, wobei nur sie und Mitglieder dieser Gruppe das Thema sehen können?
Das wäre eine Wunderwaffe für diesen Anwendungsfall. Wir hätten eine klar definierte “Support”-Kategorie, in der jeder Benutzer seine (und nur seine) Support-Tickets sehen kann. Alles ist an einem Ort und Sie können Tags und alles andere verwenden.

Aber sowohl @codinghorror als auch @sam haben uns oft gesagt, dass themenspezifische Berechtigungen nicht kommen werden (was ich vollkommen verstehe, da es viel Komplexität hinzufügt).

---

Ich sehe zwei Wege nach vorne: Nutzen Sie die Gruppen-Posteingänge unter #3 und hoffen Sie, dass diese Nachteile behoben werden, oder geben Sie der Idee der privaten Themen unter #4 eine weitere Chance.

In der Zwischenzeit sind ein paar Plugins aufgetaucht, die mit themenspezifischen Berechtigungen herumspielen (oder diese implementieren), wie Restricted Replies – erlauben Sie nur bestimmten Gruppen, in einer Kategorie zu antworten – und Discourse Private Replies, die Antworten für alle außer dem Thema-Starter (und dem Personal) unsichtbar macht … und es scheint machbar … also habe ich erwogen, dies in einem Plugin noch einmal zu versuchen.

Aber.

Bevor ich damit fortfahre, würde ich gerne hören

• ob andere Leute meine Meinung bezüglich der Gruppen-Posteingänge teilen, da ich weiß, dass diese wahrgenommenen Nachteile sehr subjektiv sein könnten.
• jedes (!!) Feedback zu der Idee des Plugins für private Themen.

[Heliosurge (Dan DeMontmorency)]

Dies ist in der Tat ein sehr gutes Thema zur Diskussion.

Die privaten Antworten könnten möglicherweise ausgegliedert werden, um etwas Ähnliches wie Ihre Idee zu entwickeln. Aber es würde jemanden erfordern, der weiß, was er tut oder diskutiert, vielleicht mit dem Plugin-Autor, falls es sich um eine gesponserte Plugin-Fork handelt. Mit Sponsoring wäre dies großartig, um eine Form des Crowdfunding-Konzepts zu erkunden.

Discourse Private Replies

Github: GitHub - communiteq/discourse-private-replies This plugin hides topic replies for everyone but the topic starter and the post author. Use cases This can be used for for instance homework assignments where the teacher opens a topic and posts an assignment, and all students make a post with their answers. When everyone has submitted their work, the teacher can open up the answers so the students will be able to discuss them. A second use case can be an auction where something is offered…

---

Die Gruppen-Mailbox ist eine großartige Idee, aber meiner Meinung nach muss das PM-System eine einfach zu bedienende Suchfunktion oder Gruppen-Lesezeichen mit einer Ordneroption haben. Z.B. Kundenanfragen A Okt. 2020.

[Simon_Manning]

@RGJ

Aber sowohl @codinghorror als auch @sam haben uns oft gesagt, dass themenspezifische Berechtigungen nicht kommen werden (was ich vollkommen verstehe, da dies viel Komplexität hinzufügt).

Ohne den ursprünglichen Kontext zu kennen, scheinen themenspezifische Berechtigungen ein viel breiteres (und wie Sie sagten, viel komplexeres) Unterfangen zu sein, als das, was erforderlich wäre, um #4 zu ermöglichen.

So, wie ich mir das vorstellen würde, würde dies durch die Erweiterung der Kategorieberechtigungen um „Eigene anzeigen“ geschehen. Ähnlich wie die Berechtigungen jetzt sind, muss eine der Optionen „Anzeigen“ oder „Eigene anzeigen“ für eine hinzugefügte Gruppe erlaubt sein.

Da „Erstellen“ automatisch „Antworten“ erlaubt, würde „Jetzt anzeigen“ automatisch „Erstellen“ erlauben – eine Kategorie, in der man nur seine eigenen Themen sehen kann, wäre ziemlich sinnlos, wenn man keine Themen erstellen kann.

Ich denke, dies würde „nur“ zwei zusätzliche Änderungen im Bereich der Berechtigungen erfordern. Wenn die Gruppen, zu denen der aktuelle Benutzer gehört, nur die Berechtigung „Eigene anzeigen“ gewähren:

1. Die Themenliste sollte nach Themen gefiltert werden, die vom aktuellen Benutzer erstellt wurden.
2. Der Zugriff auf Themen sollte verweigert werden, es sei denn, das Thema wurde vom aktuellen Benutzer erstellt.

Ich vermute, dass es in der Realität zusätzliche Komplexität gibt, die sich mit Dingen wie der Liste der neuesten Themen befasst, aber wahrscheinlich (vielleicht…) keine enorme zusätzliche Arbeit.

@RGJ

• wenn andere Leute meine Meinung bezüglich der Gruppen-Posteingänge teilen, da ich mir bewusst bin, dass diese wahrgenommenen Nachteile sehr subjektiv sein könnten.

Wir bieten derzeit keinen privaten Support in Discourse an, daher habe ich keine direkte Erfahrung, aber ich denke, meine eigenen Wahrnehmungen stimmen mit Ihren überein.

Auffindbarkeit ist wichtig, sowohl beim Finden, wo man Unterstützung anfordern kann, als auch beim Überprüfen aktueller und vergangener Supportanfragen, was mit dem Ansatz der Gruppen-PMs potenziell herausfordernd erscheint.

[RGJ (Richard - Communiteq)]

@Heliosurge

Die privaten Antworten könnten vielleicht ausgegliedert werden, um etwas Ähnliches wie Ihre Idee zu entwickeln. Aber es würde jemanden erfordern, der weiß, was er tut oder diskutiert, vielleicht mit dem Plugin-Autor, falls es sich um eine gesponserte Plugin-Ausgliederung handelt. Mit Sponsoring wäre es großartig, eine Form des Crowdfunding-Konzepts zu erkunden.

Vielen Dank für Ihr Feedback! Ich bin zufällig der Autor dieses speziellen Plugins, und wir (Communiteq) sind bereit, hier zu investieren, wenn wir das Gefühl haben, dass dies die richtige Richtung ist. Diese Dinge werden also kein Problem sein.

@Simon_Manning

Ich denke, dies würde „nur“ zwei zusätzliche Änderungen im Bereich der Berechtigungen erfordern. Wenn die Gruppen, zu denen der aktuelle Benutzer gehört, nur die Berechtigung „Eigene sehen“ gewähren:

• Die Themenliste sollte nach Themen gefiltert werden, die vom aktuellen Benutzer erstellt wurden.
• Der Zugriff auf Themen sollte verweigert werden, es sei denn, das Thema wurde vom aktuellen Benutzer erstellt.

Ja, das klingt richtig.

Ich kämpfe immer noch ein wenig damit, wie das genau strukturiert werden würde, da Eigene sehen Erstellen impliziert, Erstellen Antworten impliziert und Antworten Sehen impliziert.
Aber wir möchten nicht, dass Eigene sehen Sehen impliziert.

[Heliosurge (Dan DeMontmorency)]

Ja, das sehe ich. Hätte besser aufpassen sollen.

[Simon_Manning]

@RGJ

Ich habe jedoch noch ein wenig damit zu kämpfen, wie dies genau strukturiert werden würde, da Eigene ansehen Erstellen impliziert, Erstellen Antworten impliziert und Antworten Ansehen impliziert.
Aber wir wollen nicht, dass Eigene ansehen Ansehen impliziert.

Ja, das scheint kniffliger zu sein, als ich dachte. Es sieht so aus, als ob Antworten nicht wirklich Ansehen impliziert, aber eine Gruppe, die zu Kategorieberechtigungen hinzugefügt wird, das schon tut.
Die Berechtigungen sind eine Aufzählung, bei der eine Gruppe genau eine der Berechtigungen readonly, create_post oder full hat. Um herauszufinden, ob ein Benutzer in einer bestimmten Kategorie antworten/erstellen kann, muss man eine Liste aller Kategorien abrufen, in denen der Benutzer Teil einer Gruppe ist, die (create_post oder full) zum Antworten oder (full) zum Erstellen eines Themas hat, und prüfen, ob die relevante Kategorie in dieser Liste enthalten ist.
Das Erstellen von Themen ist einfach, ein zusätzlicher Wert in der Aufzählung wie full_own funktioniert einfach damit, dass er zur Konstante TOPIC_CREATION_PERMISSIONS in category.rb hinzugefügt wird. Wenn der Benutzer entweder full oder full_own für die relevante Kategorie hat, kann er ein Thema erstellen.
Antworten sind komplizierter, aber ich denke, es wäre angemessen, einen zusätzlichen Geltungsbereich hinzuzufügen, der alle Kategorien zurückgibt, in denen der Benutzer full_own hat. So etwas wie:

  OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
  scope :own_topic_post_create_allowed,  -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }

Dann muss in post_guardian.rb can_create_post? eine zusätzliche Bedingung haben, wie zum Beispiel:

    (!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
      !parent ||
      !parent.category ||
      Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
      (parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
    )

Das Anzeigen nur eigener Themen und die Gewährleistung, dass dies auf der relevanten Kategorieseite, im neuesten Feed, in der Suche und überall sonst zutrifft, erscheint jedoch viel schwieriger. Das habe ich noch nicht herausgefunden.

[tobiaseigen]

Ich denke, die am einfachsten zu erreichende Verbesserung ist die Tür Nummer 3: die Verbesserung von Gruppen-E-Mails, damit sie gut für die Unterstützung von Personen funktionieren, die sich anmelden, und nicht nur für Personen, die eine E-Mail zur Unterstützung senden.

@RGJ

• Nachrichten, die an die Support-Gruppe gesendet werden, sind schwer zu finden (eigentlich sind IMHO alle Nachrichten schwer zu finden, wenn man keine Benachrichtigung zum Anklicken hat) und obwohl das Support-Personal einen guten Überblick hat, hat ein Benutzer keinen. Wo die Mitarbeiter, die an den Tickets arbeiten, eine separate Gruppen-E-Mail sehen, können Benutzer, die die Tickets erstellt haben, diese nur zwischen ihren „regulären“ PMs finden.
• Mangelnde Tag-Unterstützung in PMs: Nur Mitarbeiter können PMs taggen und Benutzer können Tags nicht sehen oder danach filtern.
• Es gibt keinen „Ort“, an den man gehen und eine Nachricht senden kann. Die Möglichkeit, das Support-Team zu kontaktieren, muss irgendwo explizit beworben werden (und ich finde es schwer, einen logischen Ort dafür zu finden, meistens landet es in irgendeiner Art von Banner).

Ihre Hauptbeschwerden über Gruppen-E-Mails scheinen sich auf den Mangel an Funktionalität auf Benutzerseite zu beziehen, was legitim ist, wenn Ihre Benutzer sich anmelden, um Tickets zu verfolgen, und auch PMs verwenden, um mit anderen Personen auf der Website zu sprechen. Ich habe dies bisher bei unserer Nutzung von Gruppen-E-Mails zur Unterstützung hier auf Meta noch nicht sehr oft erlebt. Die meisten Leute, die wir über die Gruppen-E-Mails unterstützen, melden sich nie an – sie verwenden hauptsächlich ihre eigene E-Mail und können so ihre E-Mail verwenden, um ihre Korrespondenz mit uns nach Belieben zu organisieren und zu archivieren.

Ich habe ein paar Benutzer, mit denen ich hier auf Meta über @support-teams kommuniziere, also werde ich sie fragen, wie es für sie funktioniert und ob sie Vorschläge haben. Ich werde auch selbst weitere Tests durchführen, um zu sehen, wie dies jetzt tatsächlich funktioniert. Es scheint mir, dass die Anfrage lautet:

• Nicht-Mitarbeitern erlauben, Nachrichten-Tags zu sehen (derzeit sehen nur Mitarbeiter Tags. Vielleicht können wir Tag-Gruppen dafür verwenden, um einige Tags bereitzustellen, die Nicht-Mitarbeiter in Nachrichten sehen können? )
• Bereitstellung eines Links zu Gruppen-E-Mails im Nachrichtenmenü für Benutzer, wenn sie Gruppen kontaktieren, um eigene Nachrichten mit Gruppen anzuzeigen (dies funktioniert bereits für Mitarbeiter, ich bin mir nicht sicher, wie es für Nicht-Mitarbeiter funktioniert. Es gibt hier Probleme mit Posteingang und Archiv, die nicht individuell pro Benutzer gesteuert werden)
• Bereitstellung eines Links zum Starten einer neuen Nachricht an eine Gruppe (ich glaube, dies existiert auf der Gruppenseite, wenn das Senden von Nachrichten an die Gruppe erlaubt ist)

Die Möglichkeit, eine neue Nachricht an eine Gruppe zu senden, ist etwas, das mir sogar als Mitglied der @support-teams-Gruppe zur Bereitstellung von Discourse für Teams E-Mail-Support aufgefallen ist. Wenn ich eine neue Nachricht vom Support-Team starten möchte, muss ich sowohl das Support-Team als auch die E-Mail-Adresse der Person angeben, an die ich schreiben möchte. Das ist etwas umständlich.

Außerdem schließen wir bei der Nutzung von Gruppen-E-Mails Nachrichten normalerweise nicht ab, wie wir es bei Themen tun, wenn sie gelöst sind. Wir archivieren sie einfach. Dies ermöglicht es uns, sie aus dem Blickfeld zu bekommen, wenn sie gelöst sind, aber auch dem Kunden zu ermöglichen, per E-Mail nachzufassen und die Nachricht zurück in den Posteingang zu verschieben.

[Simon_Manning]

@tobiaseigen

Außerdem schließen wir bei der Verwendung von Gruppen-Posteingängen Nachrichten normalerweise nicht ab, wie wir es bei Themen tun, wenn sie gelöst sind. Wir archivieren sie einfach. Dies ermöglicht es uns, sie auszublenden, wenn sie gelöst sind, aber auch dem Kunden zu ermöglichen, per E-Mail nachzufassen und die Nachricht zurück in den Posteingang zu verschieben.

Das ist ein ziemlich interessanter Punkt, den ich mir noch nicht wirklich überlegt hatte. Bei der E-Mail-Unterstützung ist es sehr üblich, dass Kunden alte E-Mails finden und darauf antworten, anstatt eine neue E-Mail zu senden. Wenn ein Thema geschlossen wird, ist das wahrscheinlich bestenfalls verwirrend, wenn ihre E-Mail abgelehnt wird.

Hinter Tür Nummer 4, wie auch immer das geschehen könnte, wäre es für die Mitarbeiter wahrscheinlich schwierig, nicht bearbeitete Themen zu identifizieren, wenn sie nicht geschlossen werden können, insbesondere bei einer größeren Anzahl von Supportmitarbeitern. Das Solved-Plugin wird hier nicht wirklich helfen, da der Kunde auf ein altes Thema antworten könnte und die verschiedenen Supportmitarbeiter nicht wissen, ob es Aufmerksamkeit benötigt oder ob ein anderer Mitarbeiter es bereits gelöst hat.

[RGJ (Richard - Communiteq)]

Ich bin mir nicht sicher, ob das Herumspielen mit full, create_post und readonly der richtige Weg ist, da full und create_post an vielen Stellen „alles sehen“ implizieren. Es wird nicht einfach sein, auf diese Weise ein wartbares Plugin zu erstellen. Außerdem denke ich, dass es nicht sehr intuitiv wäre.

Außerdem wäre es cool, wenn der Themaersteller in der Lage wäre, zusätzliche Personen (z. B. einen Kollegen) zum Thema hinzuzufügen, zum Beispiel indem er sie erwähnt, und in diesem Fall würde dieser Mechanismus nicht ausreichen.

Im Moment ist meine Idee, die Berechtigungen unverändert zu lassen und einen Abschnitt unter den Sicherheitsgruppen hinzuzufügen:

---

Private Themen in dieser Kategorie aktivieren
Erlaube den folgenden Gruppen, alle Themen zu sehen [x Support-Mitarbeiter] [x Vertriebsmitarbeiter]

---

@Simon_Manning

Es ist jedoch viel schwieriger, nur die eigenen Themen zu sehen und dies auf der relevanten Kategorieseite, den neuesten Beiträgen, der Suche und überall sonst zu gewährleisten. Das habe ich noch nicht herausgefunden.

Ich habe etwas Ähnliches im Plugin für private Antworten gemacht, aber dann für Beiträge in einem Thema anstelle von Themen in einer Kategorie.
Ich denke, ich werde mit einigen Patches in TopicGuardian ziemlich weit kommen.

@tobiaseigen

Ich denke, die am einfachsten zu erreichende Frucht ist Tür Nummer 3, die Verbesserung von Gruppen-Posteingängen, damit sie gut funktionieren, um Leuten, die sich anmelden, Support zu bieten, nicht nur Leuten, die per E-Mail Support erhalten.

Ja, das könnte eine sehr einfach zu erreichende Frucht sein. Ihre Zusammenfassung meiner Anfrage ist korrekt, und ich habe zwei weitere Dinge gefunden, die Nachrichten mehr mit Themen gleichstellen würden.

• Wenn ich im Forum suche, muss ich explizit in:private zu meiner Suchanfrage hinzufügen, um meine Nachrichten zu durchsuchen. Manchmal erinnere ich mich wirklich nicht mehr, ob etwas ein (mehr oder weniger öffentliches) Thema oder eine PM an eine Gruppe war. Warum nicht standardmäßig einbeziehen?

• Außerdem denke ich, es wäre schön, wenn es einen einfachen Link zu den Nachrichten im rechten Tab des Hamburger-Menüs gäbe. Ja, es gibt das Umschlag-Symbol, aber es hat eine Liste von Nachrichten und keinen Link zum Nachrichtenbildschirm unter /my/messages. Dieser Bildschirm fühlt sich versteckt an.

Die Elemente in der Dropdown-Liste sind teilweise dieselben wie die Tabs auf dem nächsten Bildschirm, mit Ausnahme von Nachrichten und Abzeichen. Wenn ich also zu meinen Nachrichten gehen muss, klicke ich immer auf Zusammenfassung und dann auf Nachrichten.

Vergleichen Sie die Elemente in der Dropdown-Liste

mit den Tabs auf dem Profilbildschirm

Es gibt Zusammenfassung, Aktivität, Einladungen und Einstellungen in beiden, aber Entwürfe in einer und Benachrichtigungen, Nachrichten und Abzeichen in der anderen. Daher fühlen sich „Nachrichten“ für mich sehr versteckt an (das gilt auch für Benachrichtigungen und Abzeichen, aber ich benutze sie nicht so oft).

[tobiaseigen]

@RGJ

• Wenn ich im Forum suche, muss ich explizit in:private zu meiner Suchanfrage hinzufügen, um meine Nachrichten zu durchsuchen. Manchmal weiß ich wirklich nicht mehr, ob etwas ein (mehr oder weniger öffentliches) Thema oder eine PM an eine Gruppe war. Warum werden sie nicht standardmäßig einbezogen?

Guter Punkt. Ich bin mir nicht sicher, was die Überlegungen hinter dieser Barriere sind. Mir ist auch aufgefallen, dass, wenn man sich in seinen Nachrichten befindet, in:personal standardmäßig hinzugefügt wird, was gut ist! Aber es wird nicht z. B. in:support-teams hinzugefügt, um nur den Gruppen-Posteingang nach Nachrichten zu durchsuchen, was meiner Meinung nach eine gute Idee wäre. Die erweiterte Suche hat auch keine einfache Möglichkeit, nach Gruppen-Posteingang zu filtern, soweit ich weiß. (cc @pmusaraj)

@RGJ

Zusätzlich denke ich, es wäre schön, wenn es einen einfachen Link zu den Nachrichten im rechten Reiter des Hamburger-Menüs gäbe. Ja, es gibt das Umschlag-Symbol, aber es hat eine Liste von Nachrichten und keinen Link zum Nachrichtenbildschirm unter /my/messages. Dieser Bildschirm fühlt sich versteckt an.

Das ist eine gute Idee, aber ich denke, es gibt ein Problem mit dem Platz in diesem Dropdown-Menü – man möchte nicht mehr als 7 Elemente in dieser Liste haben. Außerdem glauben wir für die meisten Communities nicht wirklich, dass wir Messaging fördern wollen… wir wollen, dass die Leute öffentlich reden! Für diejenigen, die per Nachricht kommunizieren, bieten das Benachrichtigungs-Dropdown und E-Mail-Benachrichtigungen usw. reichlich Gelegenheit, auf die benötigten Nachrichten zuzugreifen.

Das gesagt, wir arbeiten aktiv an Verbesserungen des Menüsystems (Stichwort: Sideburger), werden dieses Problem also berücksichtigen. Die Seitenleiste in Discourse for Teams bietet bereits einfachen Zugriff auf Gruppen-Posteingänge und beobachtete Tags, die wir zusammen mit dem Sideburger-Projekt in den Kern von Discourse integrieren können.

So sieht es jetzt aus, wenn ich mich im Kabissa-Gruppen-Posteingang auf meiner Discourse for Teams-Website befinde:

[Simon_Manning]

@tobiaseigen

• einen Link zum Starten einer neuen Nachricht an eine Gruppe bereitstellen (ich glaube, das gibt es auf der Gruppenseite, wenn das Senden von Nachrichten an die Gruppe erlaubt ist)

Ich frage mich, ob Gruppen als Support-Gruppen ausgewiesen werden können und basierend darauf ein Hamburger-Menü-Eintrag mit diesen Zuständen vorhanden ist:

• 0 Gruppen als Support ausgewiesen, kein Menüeintrag
• 1 Gruppe ausgewiesen, ein Eintrag „Support-Nachricht“, der eine Nachricht an die Gruppe startet

• 1 Gruppe ausgewiesen, ein Eintrag „Support“, der zu einer Seite ähnlich wie Gruppen verlinkt und alle ausgewiesenen Gruppen mit Nachrichten-Buttons anzeigt

Vielleicht sind der zusätzliche Menüeintrag und die Seite übertrieben. Ein zusätzlich generierter Abschnitt auf der Info-Seite?

@RGJ

• Außerdem fände ich es schön, wenn es im rechten Reiter des Hamburger-Menüs einen einfachen Link zu den Nachrichten gäbe. Ja, es gibt das Briefumschlag-Symbol, aber es zeigt eine Liste von Nachrichten und keinen Link zum Nachrichtenbildschirm unter /my/messages. Dieser Bildschirm wirkt versteckt.

Es ist nicht ganz offensichtlich, aber dieser ist im Nachrichten-Tab vorhanden, der nach unten zeigende Pfeil am Ende der Nachrichtenliste führt Sie zum Bildschirm /my/messages. Nicht weniger Klicks als Zusammenfassung, dann Nachrichten, aber eine Seitenladung weniger.

@tobiaseigen

So sieht es jetzt aus, wenn ich mich im Posteingang der Kabissa-Gruppe auf meiner Discourse for Teams-Website befinde:

Wenn ich ein Benutzer wäre, der eine Nachricht an Kabissa sendet, wäre dieses Thema dann in irgendeiner Weise primär mit der Gruppe verbunden, oder hätte das Thema nichts weiter als meinen Benutzer und die Kabissa-Gruppe, die Zugriff haben?

Wenn es primär mit der Gruppe verbunden wird, wäre es dann möglich, diesen Kabissa-Posteingang auf meiner Nachrichten-Seite auf die gleiche Weise anzuzeigen, wenn auch offensichtlich nur mit Nachrichten, auf die ich Zugriff habe.

[tobiaseigen]

Als ich dies hier auf Meta getestet habe, indem ich einen tl0-Benutzer erstellt habe, konnte ich zur Support-Teams-Gruppenseite navigieren und die Schaltfläche Nachricht auswählen, um der Gruppe eine Nachricht zu senden. Sobald ich die Nachricht gepostet hatte, landete sie in meinem Ordner Gesendete Nachrichten. Das funktioniert also, ist aber vielleicht für einige Fälle etwas zu versteckt. Sie können dem Hamburger-Menü jederzeit Links hinzufügen, wie Sie es für Ihre Website für richtig halten, oder in einem Banner auf Ihrer Homepage usw. Ich sehe also nicht viel mehr, was hier getan werden muss?

Die Kabissa-Inbox auf diesem Screenshot wird nur Leuten in der Kabissa-Gruppe angezeigt. Leute, die Kabissa eine Nachricht senden, sehen die Nachrichten in ihren eigenen Nachrichten.

[jomaxro (Joshua Rosenfeld)]

@RGJ

• Wenn ich im Forum suche, muss ich explizit in:private zu meiner Suchanfrage hinzufügen, um meine Nachrichten zu durchsuchen. Manchmal weiß ich wirklich nicht mehr, ob etwas ein (mehr oder weniger öffentliches) Thema oder eine PM an eine Gruppe war. Warum nicht standardmäßig einbeziehen?

Beachten Sie, dass in:all existiert. Dies zeigt sowohl öffentliche als auch persönliche Nachrichten in einer einzigen Suche an.

Wenn ich mich richtig erinnere, war die Idee, die Trennung zwischen persönlichen Nachrichten und öffentlichen Themen zu erzwingen. Minimieren Sie jegliche Verwirrung darüber, was öffentlich und was persönlich ist. Allerdings verwischen Gruppen-Posteingänge diese Trennung erheblich.

[Simon_Manning]

@tobiaseigen

Sie können dem Hamburger-Menü jederzeit Links hinzufügen, wie es den Zwecken Ihrer Website entspricht, oder in einem Banner auf Ihrer Homepage usw. Daher sehe ich nicht, dass hier noch viel mehr getan werden muss?

Ich dachte daran, die Auffindbarkeit von support-spezifischen Gruppen zu erhöhen. Das Hinzufügen von Links zum Hamburger-Menü wäre sicherlich für eine Community mit einer einzigen Support-Gruppe geeignet (was für meine eigenen Zwecke ideal ist), aber eine Community mit vielen Support-Gruppen könnte von einer Seite oder einem Abschnitt auf der Über-uns-Seite profitieren, die für bestimmte Gruppen generiert wird.

Rückblickend ist dies wahrscheinlich besser für ein Plugin geeignet, wenn eine Community dies benötigt.

@tobiaseigen

Die Kabissa-Inbox in diesem Screenshot wird nur Personen in der Kabissa-Gruppe angezeigt. Personen, die Kabissa Nachrichten senden, sehen die Nachrichten in ihren eigenen Nachrichten.

Was ich zu fragen versuchte, vielleicht schlecht formuliert, war, ob das Modell derzeit genügend Informationen hat, um es (in Zukunft) zu ermöglichen, Benutzern gefilterte Inboxes für Gruppen anzuzeigen, mit denen sie interagieren, aber denen sie nicht angehören. Dies bezieht sich auf die Bedenken von @RGJ, dass Nachrichten, die an Gruppen gesendet werden, schwer zu finden sind.

Zum Beispiel, dass ich als normaler Benutzer auf Ihrer Discourse for Teams-Website eine Kabissa-Inbox in meinen Nachrichten sehen kann, die alle Nachrichten anzeigt, die ich an die Kabissa-Gruppe gesendet habe. (Oder wahrscheinlich Nachrichten, an denen ich beteiligt bin.)

Mein Verdacht ist, dass dies nicht der Fall ist, sondern wahrscheinlich nur die Teilnehmer berücksichtigt, die eine beliebige Anzahl von Benutzern und Gruppen sein können.

[schungx (Stephen Chung)]

@RGJ

In den letzten Monaten habe ich mit ziemlich vielen Leuten gesprochen, die versuchen, direkten Kundensupport einzurichten – bei dem ein Support-Team (vertrauliche) kundenspezifische Probleme löst – als Ergänzung zu ihrem bestehenden (öffentlichen) Community-Support-Forum.

Es ist großartig, dass sich das durchsetzt! Das liegt daran, dass ich feststelle, dass Discourse ein fantastisches System für private Support-Tickets ist und, wenn es funktioniert, wunderbar funktioniert.

Ich weiß sehr wohl, dass dies nicht das ist, wofür Discourse entwickelt wurde, und dass ich versuche, Discourse in etwas hineinzuzwängen, das es nicht tun soll, aber zwischen privaten Posteingängen und dem vollen Glanz und den Funktionen von Hauptthemen würde ich letzteres jeden Tag wählen und weiterhin versuchen, es hineinzuzwängen…

[codinghorror (Jeff Atwood)]

@schungx

Ich weiß sehr wohl, dass dies nicht das ist, wofür Discourse entwickelt wurde, und dass ich versuche, Discourse für etwas zu missbrauchen, wofür es nicht gedacht ist, aber zwischen privaten Posteingängen und dem vollen Glanz und den Funktionen von Hauptthemen würde ich letzteres jeden Tag wählen und weiterhin versuchen, es zu missbrauchen…

Dies ist etwas, das wir unterstützen wollen (bildlich und wörtlich), aber wir wollen nicht in die Ecke eines „Support-Tools“ gedrängt werden. Wenn Sie spezifisches Feedback haben, wie wir Discourse in dieser Rolle besser machen können, lassen Sie es uns wissen.

Wir hören immer zu

[jrgong]

@RGJ

Was wäre, wenn es eine Art „Drop-Box“-Kategorie gäbe, in der Leute ein Thema starten und mit dem Support-Personal interagieren können (im Grunde: eine Gruppe), in der nur sie und Mitglieder dieser Gruppe das Thema sehen können?

Ich liebe die Idee! Selbst aus unserer Community erhalten wir Anfragen nach Support-Tickets, die getrennt von ihrem Benutzer-Posteingang sind. Diese Art von Kategorie, in der Benutzer nur ihre eigenen Tickets sehen können, wäre äußerst hilfreich.

[jerry0 (Jerry)]

@codinghorror

Das ist etwas, das wir unterstützen wollen (im übertragenen und wörtlichen Sinne), aber wir wollen nicht in die Ecke eines „Support-Tools“ gedrängt werden. Wenn Sie spezifisches Feedback haben, wie wir Discourse in dieser Rolle verbessern können, lassen Sie es uns wissen.

Danke!

Wir verwenden eine PM-Gruppe für privaten Support – das funktioniert gut. Die Hauptbeschwerde von Heavy-Usern des Support-Systems ist die Unfähigkeit, ihre Nachrichten zu durchsuchen.

Wir haben versucht, ihnen beizubringen, dass sie den Code in:personal zur Suchanfrage hinzufügen müssen, um ihre Nachrichten zu durchsuchen, aber das ist nicht intuitiv und ehrlich gesagt habe ich noch keinen einzigen Benutzer gesehen, der dies tatsächlich schafft. Sie geben einfach auf und beschweren sich, dass sie ihre Nachrichten nicht durchsuchen können.

Sie verstehen nicht einmal, wozu dieser „Vorschlag“ unterhalb des Suchfeldes dient.

Und wenn sie zur erweiterten Suche gehen, sind sie vielleicht fortgeschritten genug, um die Radio-Schaltfläche „Nachrichten durchsuchen“ anzukreuzen, aber alles beginnt seltsam auszusehen, wenn dadurch die Wörter in:personal hinzugefügt werden und sie an diesem Punkt aufgeben.

Wenn es eine viel intuitivere Möglichkeit gäbe, Nachrichten zu durchsuchen, die nicht das Hinzufügen von Code zum Suchfeld beinhaltet, wäre das eine massive Verbesserung.

Wenn nicht, wäre die Verwendung einer intuitiveren Sprache, z. B. des Codes „in:messages“, eine leichte Verbesserung.

[pfaffman (Jay Pfaffman)]

Oder vielleicht soll die Suche standardmäßig PMs einschließen?

[jerry0 (Jerry)]

In der Tat – das wäre wunderbar!

Eine Einstellung „PMs standardmäßig durchsuchen“ (die normalerweise deaktiviert ist) wäre wirklich ideal.

Auf diese Weise könnten Bedenken, dass Benutzer zwischen Suchergebnissen für normale Themen und PM-Themen (die ich nicht habe) verwechselt werden, gegen die Tatsache abgewogen werden, dass Personen PM-Themen überhaupt nicht durchsuchen können (was ich habe).