Wir setzen voll auf Tags, weil sie eine unglaubliche teamsübergreifende Flexibilität bieten, besonders in Kombination mit Projektmanagement-Plugins wie Kanban-Boards, Abstimmungen und Kalender.
Wir arbeiten an einem „Tag-Navigations“-System, sodass Nutzer entweder:
die Suchleiste nutzen können, um Begriffe einzugeben und direkt zu Tags und Tag-Schnittpunkten zu springen. Die native Suchleiste verfügt bereits über diese Funktion; wir machen sie einfach zum Standardverhalten und platzieren sie in einem Banner.
die Hauptansicht Tag-Seiten in Boxen anzeigt, genauso wie das Forum derzeit Kategorien im Box-Modus darstellt. Das bedeutet, Nutzer können durch Tags klicken, wobei jeder Klick einen Tag zu ihrer Tag-Schnittmenge hinzufügt und ein baumartiges Navigationssystem erstellt. Zum Beispiel: „webdev“ > „reactjs“ > „new-build“ > „fri-workteam“ > usw. > usw. … so lange, wie die Nutzer möchten.
Das Hauptproblem, das wir haben, ist, dass die meisten Plugins Tags und Tag-Seiten noch nicht unterstützen. Wir haben Kanban-Boards erfolgreich so angepasst, dass sie mit Tags und Tag-Seiten funktionieren, was fantastisch ist, denn ich kann alle „webdev“-Aufgaben sehen, an denen gearbeitet wird, oder nur die „fri-workteam“-Aufgaben, oder ich kann den „ux“-Tag hinzufügen, um zu sehen, wo die Teams zusammenarbeiten oder welche Aufgaben beide Kompetenzbereiche erfordern. Sobald wir den Teamkalender angepasst haben, habe ich dieselben Optionen, um zu sehen, wer wann arbeitet. Gleiches gilt für das Abstimmungs-Plugin, das wir nutzen, um neue Ideen, Projekte und Aufgaben auszuwählen.
Wir stehen gerade am Anfang eines großen Vorhabens, um unser Freiwilligennetzwerk zu mehr Frieden und Wohlbefinden in der Weltgemeinschaft auf das nächste Level zu bringen. Sie sind absolut willkommen, sich beim Coden zu beteiligen – hier ist wo wir entwickeln. Ich selbst und einige unserer Mitglieder haben einen beträchtlichen Betrag eingezahlt, um jemanden mit der Entwicklung zu beauftragen, da unser Ruby on Rails-Entwicklungsteam zu ruhig war und es ewig gedauert hätte.
Ich habe dies in den letzten etwa 8 Monaten mehrfach erwähnt, nachdem ich dieses Forum recherchiert und eine ständig wachsende Anzahl von Nutzern gesehen habe, die die Flexibilität von Tags in ihren Foren stärker nutzen möchten, aber dabei auf Probleme stoßen, da die meisten Hauptnavigations-Plugins und -Komponenten für Kategorien entwickelt wurden und nur wenige bisher auf die Unterstützung der neuen Tags-Funktion umgestellt haben.
Wir könnten warten, bis alle Plugin-Autoren ihre Plugins anpassen (und wie oben erwähnt planen wir, dies für einige in den nächsten ein bis zwei Monaten zu tun). Ich schlage stattdessen eine Kernlösung vor, die alle bestehenden Plugins und Komponenten sofort aktualisiert, indem sie ihnen mitteilt, dass sie Tags/Tag-Seiten wie Kategorien behandeln sollen.
Dies würde die Benutzerfreundlichkeit von Tags auf Discourse für die Nutzer erheblich verbessern, und zwar auf eine Weise, die meiner Einschätzung nach ohnehin allen zukünftigen Erweiterungen entsprechen wird. Gleichzeitig würden die Nutzer Monate oder sogar Jahre Wartezeit auf Updates zur Tags-Unterstützung erspart bleiben – und natürlich würden auch alle Plugin-Autoren eine Menge Arbeit erspart bleiben.
Es könnte einen Shortcode oder einen Umschalter geben, um diese Funktion für Plugins zu deaktivieren, deren Autoren Tags nicht unterstützen möchten, obwohl mir konkret keine solchen Plugins einfallen. Dieser Umschalter könnte auch Nutzern zur Verfügung stehen, damit sie das Verhalten ihrer Add-ons selbst ein- oder ausschalten können.
Hier sind einige Beispiele von Nutzern, die Tags stärker nutzen möchten, aber dabei auf Einschränkungen stoßen, die durch diese Lösung behoben würden. Ich habe diese aus meinen jüngsten Kommentaren zusammengestellt; es gibt viele weitere, die ich bei früheren Recherchen gefunden habe:
Ich meine nicht, dass sie im allgemeinen Sinne gleich behandelt werden sollten. Sondern vielmehr, dass ein bestimmter Teil des Core-Discourse-Codes, der von Benutzern und Plugin-Erstellern ein- und ausgeschaltet werden kann und Plugins anweist, Tags auf dieselbe Weise wie Kategorien zu erkennen, viele Plugin-Entwickler davor bewahren würde, ihre Plugins anpassen zu müssen, um Tags und Tag-Seiten zu unterstützen. Dies würde zudem eine breite Palette von Plugins für Benutzer bereitstellen, um ihre Sites weiter anzupassen, und es wurden Beispiele für Benutzer angeführt, die dies als Funktion angefordert haben.
Da Tags relativ neu sind, während Kategorien bereits gut ausgereift sind, wurden Plugins mit Blick auf Kategorien entwickelt. Immer mehr Benutzer setzen Tags zentraler ein und äußern den Wunsch, auf die Funktionen zugreifen zu können, die Plugins derzeit für Kategorien bieten.
Ich bin nicht versiert genug, um zu wissen, ob meine Vorschläge umsetzbar sind. Ich denke jedoch, dass fast alle Plugins dies individuell früher oder später unterstützen werden (wie etwa das Tag-Banners-Plugin, das das Category-Banners-Plugin nachbildet), und das ist für deren Entwickler ein langer Weg. Wenn dies im Core-Discourse gelöst werden könnte, würde das den Entwicklern enorm viel Zeit sparen und vielen Benutzern schnell zugutekommen.
Die Unterstützung von Tags wird in den kommenden Jahren in den meisten Plugins implementiert werden. Ich habe mich gefragt, ob dies im Kern umgesetzt werden könnte, um den Prozess für die Nutzer zu beschleunigen und die Entwickler davor zu bewahren, dies einzeln codieren zu müssen. Für unseren Build käme dies leider zu spät; es ist lediglich eine Idee, die ich vorschlage, da dies, falls möglich, anderen Nutzern in kurzer Zeit weit mehr Anpassungsoptionen bieten würde.
Das ist so stark verallgemeinert, dass es bedeutungslos ist.
Wenn du die erste Aussage nicht belegen kannst, verstehe ich nicht, warum Entwickler überhaupt etwas tun sollten, geschweige denn im Core.
Nur sehr wenige nutzen Tags ohne Kategorien. Wenn es einen enormen Anstieg der Nachfrage gäbe, insbesondere von zahlenden Kunden, wäre ich mir sicher, dass es dann passieren würde.
Tag-Navigation ohne Kategorien ist eines der Plugins, an dem wir arbeiten.
Ich beziehe mich auf andere Plugins und Komponenten wie: category-banners, calendar, events, kanban, voting, rating, topic-preview. Diejenigen, die Tags unterstützen, würden allen Benutzern neue Werkzeuge bieten. Ich habe auch auf Beiträge geantwortet, in denen nach Tag-Unterstützung in den Plugins banners, events, kanban, voting und navigation (eines, das wir entwickeln) gefragt wird, und den Fragesteller gebeten, ob er Ressourcen bündeln und diese entwickeln lassen möchte. Wir würden sie entweder gemeinsam für alle entwickeln oder bezahlen, falls uns die erforderlichen Fähigkeiten fehlen.
Das ist unmöglich. Es ist, als würde man sagen, man solle Windows und macOS sofort gleich behandeln. Es gibt große Unterschiede, sonst hätten wir nicht sowohl Tags als auch Kategorien.
“Wenn der Benutzer/Ersteller die Option aktiviert hat, sollen beim Abrufen von Kategorien in der Datenbank auch Tags zurückgegeben werden, wenn Plugins diese anfordern.”
oder
“Wo die Kategorien-ID verwendet wird, um das Plugin zum Bereitstellen aufzufordern, soll ebenfalls nach der Tag-ID gesucht werden, falls die Option aktiviert ist.”