Gibt es Pläne, mehrere Events pro Thread oder pro Beitrag zuzulassen?

Beitragen Merkmal
1

Gibt es Pläne, mehrere Ereignisse pro Thread oder pro Beitrag zuzulassen?

Die Anwendungsfälle, die mir spontan einfallen, sind:

  • Ausführung desselben Ereignisses für verschiedene Zeitzonen – z. B. ein Webinar
  • Möglichkeit, detaillierte Veranstaltungsinformationen für Konferenzen hinzuzufügen, um hervorzuheben: Keynotes, Öffnungszeiten der Messe, Pausenzeiten usw.
5 „Gefällt mir“
Single click activation of the Create Event modal
2

Ich bin auf diese Einschränkung gestoßen, als ich mit einem kalendergesteuerten Diskussions-Workflow in einem Studentenforum experimentiert habe.

Mein Anwendungsfall ist, dass jedes Kalenderereignis zum Anker für ein Diskussionsthema wird und nicht das Ereignis das Einzige im Thema ist.

Wenn ich beispielsweise versuche, ein Treffen mit jemandem zu vereinbaren, könnte ich mehrere mögliche Zeitfenster im selben Diskussionsthema anbieten:
\t•\tDi, 31. März — 12–13 Uhr
\t•\tMi, 1. April — 10–11 Uhr
\t•\tFr, 3. April — 15–16 Uhr

Idealerweise würde ich gerne mehrere [event]-Blöcke im selben Thema einfügen, damit:
\t•\tdie jeder vorgeschlagene Zeitpunkt im Kalender der Website angezeigt wird
\t•\tTeilnehmer sich für ein bestimmtes Zeitfenster als teilnehmend markieren können
\t•\tnachdem eine Zeit ausgewählt wurde, die anderen Ereignisse einfach entfernt oder bearbeitet werden können

Dies wird noch nützlicher, wenn das Ereignisthema sowohl als Diskussionsfaden vor als auch nach dem Ereignis dient (Tagesordnung, Notizen, Folgefragen).

Ein weiteres Beispiel aus meinem Forum sind akademische Diskussionen, bei denen:
\t•\tdie eine Vorlesung
\t•\tdie eine Sprechstunde
\t•\tund eine Überprüfungssitzung

alle mit demselben Thementhread in Verbindung stehen, aber dennoch unterschiedliche Ereignisse im Kalender sind.

Derzeit neigt der Workflow dazu, die Leute auf ein Ereignis pro Thema zu drängen, was die Diskussion fragmentiert. Die Zulassung mehrerer Ereignisse pro Thema würde es erleichtern, zusammengehörige Gespräche an einem Ort zu bündeln und trotzdem von der Kalenderintegration zu profitieren.

3

Darf ich einen alternativen Arbeitsablauf vorschlagen, um zu erreichen, was Sie vorhaben?

  1. Behalten Sie das Ereignisthema als „Anker“ bei und machen Sie im Text deutlich, dass es vorläufig ist, oder behalten Sie vielleicht einen großen Zeitraum bei
  2. Erstellen Sie im OP (oder einem nachfolgenden Beitrag) eine Umfrage mit den verfügbaren Zeitoptionen mithilfe der Funktion „Datum einfügen“
  3. Sobald die Umfrage geschlossen ist, bearbeiten Sie das Datum/die Uhrzeit des Ereignisses entsprechend.
  4. Wenn zusätzliche Ereignisse erforderlich sind, schließen Sie diese Themen und verweisen Sie auf das „Ankerereignisthema“.

Was denken Sie?

1 „Gefällt mir“
4

Dieser Workflow ergibt Sinn, wenn das Ziel lediglich darin besteht, über eine Umfrage eine Zeit auszuwählen.

In der Situation, die ich mir vorstelle, verhalten sich die Kandidatenzeiten eher wie vorläufige Termine, die im Kalender erscheinen müssen, während die Terminplanung ausgearbeitet wird.

Stellen Sie sich zum Beispiel ein Unternehmen vor, bei dem Kundenbuchungen automatisch Termine im Kalender erstellen. Gleichzeitig versuchen wir, ein Mitarbeitertreffen zu organisieren, und schlagen mehrere mögliche Zeitfenster vor.

Diese Mitarbeitervorschläge erscheinen zunächst praktikabel, aber wenn ein wichtigerer Kundentermin auftaucht, der mit einem davon kollidiert, muss dieser Slot möglicherweise verworfen oder verschoben werden. In diesem Sinne fungiert der Kalender als globale Terminansicht und nicht nur als Mittel zur Auswahl der beliebtesten Zeit.

Die Kandidatenzeiten müssen also im Kalender erscheinen, während die Diskussion noch zwischen ihnen entscheidet. Sobald eine endgültige Zeit genehmigt ist, könnten die anderen [event]-Blöcke einfach entfernt oder bearbeitet werden.

Eine Möglichkeit, wie dies funktionieren könnte, besteht darin, dass ein Thema mehrere [event]-Blöcke enthalten kann, wobei einer als Haupttermin und die anderen als vorläufige oder sekundäre Termine gekennzeichnet sind. Der Haupttermin wäre der kanonische Termin für das Thema, während die anderen während der Terminplanung einfach als Kandidaten-Slots im Kalender erscheinen würden.

Der Haupttermin könnte entweder:
\t• manuell genehmigt werden (z. B. nach Überprüfung von Konflikten mit höherrangigen Terminen) oder
\t• dynamisch aus einer Umfrage abgeleitet werden, wenn die Diskussion eine Abstimmung zur Auswahl einer Zeit verwendet.

Wenn man sich ansieht, wie das Plugin funktioniert, werden Termine bereits aus [event]-Blöcken in Beiträgen analysiert und als separate Einträge für den Kalender gespeichert. Das deutet darauf hin, dass die „ein Termin pro Thema“-Regel möglicherweise eher eine UI-Beschränkung als eine strukturelle ist.

Die Zulassung von [event]-Blöcken in mehreren Beiträgen (wobei einer optional als Haupttermin gekennzeichnet ist) könnte das derzeitige mentale Modell beibehalten und gleichzeitig Arbeitsabläufe für die Terminplanung ermöglichen, bei denen mehrere vorläufige Termine im selben Diskussionsthema existieren müssen.

1 „Gefällt mir“