Sure. I guess that is an option. You can then also use polls and checklists in the topic. But my experience has been that more people will provide info if they are asked questions in an event registration form rather than asked to reply with info.
This is all shaping up wonderfully. You are doing a great job with a complex bit of functionality!
@joffreyjaffeux After looking more closely at the code and functionality, I just want to reiterate that I like what you’ve done here
For example, I was initially worried about the use case of editing an existing event, which I thought might need to be done via markdown. However you’ve added that neat menu for the cooked content. Nice work.
Here are some initial thoughts on the current plugin and roadmap.
Event v Date v Calendar
If you just install the discourse-calendar plugin (and nothing else), there are three types of time-related items you can add to a Discourse composer, [event], [calendar] and [date]. The use cases for these, and how they interact, are getting a little muddled if you’re not already familiar with the plugins themselves and Discourse in general.
For example, the existing discourse-calendar plugin requires you to create [dates] in posts in the same topic as the [calendar]. This [event] feature set (which is in the same plugin), requires you to create [events], which are different from [dates], but also are added to a calendar that looks exactly the same as the topic-specific [calendar] which included the [dates], but acts quite differently.
I’m also wondering about the “legibility” of this from a code perspective. Reading the code I found it somewhat tricky to keep all the “Event” and “Calendar” classes and methods straight in my head. If someone was coming to the code blind in 2 years time I think they may find it hard to follow, not because it’s poorly written, but just in terms of naming.
As the code of the Discourse Event features is already somewhat seperate from that of the Discourse Calendar features, I’m wondering if it’s feasible to make these two seperate plugins to allow for a bit more clarity around their functionality and use? In any event, interested in your thinking about this distinction on both a product and code level and where it’s heading. This will help us think through how we help people migrate from the events plugin as well.
Somewhat relevant to this is some thoughts around the rendering of the calendar itself (see below). If the new [event] functionality were separated from the use of full-calendar I wonder whether it would continue to make sense to keep it in the discourse-calendar plugin.
Relatedly, for many of the current users of the events plugin, further clarification will be needed on the [event] / [date] distinction in the composer UI. The icons and terms used are essentially synonymous to most users, and the controls for both are in essentially the same place. I’m not sure this issue is remedied by putting the Events button in the gear menu.
If you’re reticent to change this, I’m wondering if there could be a way to address this via a theme component in relevant cases. I wonder if there’s a stable way to allow other parts of the composer to interact with the toolbar / markdown, which would allow a kind of composer UI like the events plugin currently has in cases where the current UX is an issue.
The Events Plugin is largely structured around categories in response to the use case(s) of various communities. The most frequent structure we’ve seen with the events plugin is a seperate “Events” category, or sometimes multiple events sub-categories. The site-wide events calendar (which is also possible with the events plugin) or agenda is relatively rare.
The scoping of events in this plugin is currently mostly built around groups, and I understand this in response to the use case(s) this was built for. Most use cases of the events plugin I’ve seen are not in communities with defined user-groups however.
I don’t see category-specific permissions on your roadmap so I’m wondering how open you are to a PR in that respect.
I’m wondering about the use cases for having a seperate title for the event, different from the topic title, given you can only create events in the first post of a topic. Could you explain this a bit?
One potential issue I can see with this (without understanding more about the use case) is that there can be a mis-match between the title associated with the date/time in the topic list and site header and the title you see in the event item in the topic.
When the event is exported to different clients via .ics files or feeds I’m assuming the custom title (if it exists) will show up there?
There’s currently no explicit timezone support. I’m sure you’ve considered this, so I’m wondering what your thinking is here? Will it be similar to the timezone handling for [dates]?
One of the most frequent requests I got over the years with the events plugin was the ability to format the time and timezones for events in different ways.
After trying a few different approaches, I found the best way of handling this is by allowing the user to supply a moment-js format pattern via site settings. I can see this working with the structure you’ve built. Is that something you’re already thinking about, or would be open to a PR on?
All day events
Currently, the plugin doesn’t support all day events without start and end times. The issue with multi-day events with specific start and end times is that people don’t want the event taking up large portions of their calendar.
Are there any plans to allow for this in the future? I can see it being worked into the markdown options, however I’m wondering about the roadmap here, given that there are already site settings to add default times to events without times.
I’m wondering if/how you’re planning to manage event sequences given that you’re supporting .ics files and or ical feeds. There’s some discussion of the relevant RFCs here (once you get past the discussion about UIDs), with some useful input from others, including @md-misko:
Currently you’re using full-calendar to render the calendar. This is fine for some basic use cases however you run into limitations with it for a number of Discourse-relevant use cases. One of the out-of-the-box limitation is the responsive/mobile view, which affects a significant % of users.
As an example, I’ve added three events on June 1 in a mobile calendar in the current Discourse Events plugin. Firstly, the height is fixed, so I actually don’t see them on initial load. Then when I scroll inside the calendar element I see
It’s not straightforward (or sometimes possible at all) to handle responsive issues with full calendar. It’s not without cause that you’ll find a fair bit of chatter about issues with full calendar on mobile devices and various “mobile friendly” forks.
In addition to responsive view, other limitations of using full calendar that come to mind include the ability to easily add additional controls (such as feed links), fine-grained control over style and easy to control event popups.
If I was going to suggest you adopt anything from the events plugin it would probably be a version of the calendar components. They’re already isolated components set up to work with Discourse, and they’re probably the most stable part of the events plugin. I haven’t changed them in a long time. I’d be willing to adapt them to this plugin if you’re open to a PR along those lines.
In addition to perhaps having a way to add controls to other parts of the composer that allow you to stably interact with [event] markdown another integration point that is relevant to various use cases we currently support is the ability to add other details to events.
The most common use case is adding locations to events via the Locations Plugin. The events and locations plugins already play nicely together as they essentially have the same structure (they were actually originally going to be one plugin, until I realised that was a bad idea…).
A basic version of this kind of integration should be relatively straightforward, assuming it’s possible to add a plugin-outlet to the post-event template. Would that be doable?
Things we could help with (summary)
To summarise, these are some things we’ve initially considered we could help with:
Usability modifications to the composer UX, perhaps via the api or other integration hooks if possible.
Adding category-specific permissions
Time formatting in topic list items and in post event details.
Improving the calendar, particularly the responsive version, potentially by using the existing events plugin calendar components.
Also open to suggestions on areas we could potentially help with, i.e. other things I haven’t listed above, but you’re considering.
It’s been made this way for a smoother transition while we find an implementation we like. The goal being to have only one way to create events in the ends, and ofc you will still be able to display dates.
I don’t understand what’s your proposal here.
No PR for now please, I’m not against this but don’t want to rush this for now.
I will see how it’s used, I’m not super attached to this. To be honest when I added this I had in mind to be able to have multiple events per topic and even per post, we back pedalled on this but didn’t remove it. I thought it would be nice, but maybe won’t be used, we will see.
Yes it’s written on the roadmap to allow people to create events with another timezone as reference. And probably a lot of other stuff to handle down the road…
Yes I have seen this requested, this is very easy to do, I just don’t want to focus on this for now. I don’t see this as something refraining adoption and more a nice to have, so no hurries. Could accept a PR on this.
I’m working on it this week.
I will change how we do cal sync, I’m waiting for a core commit from @david and will then rethink all of this, I have no particular insights on this ATM, but the reads were interesting thanks.
Yes agreed, and I didn’t detail it, but this is part of the changes I want for this page. I haven’t discussed of this with @sam yet. I’m not interested in using discourse-events component at this point as there are quite a lot of things I want to do differently, as far as I can see it seems you are more or less trying to implement something close to what basecamp calendar does, which is also more or less my target.
post-event is a widget, so no plugin outlets, but I could add decorators or even a dedicated API, this kinda tricky because we want a fixed height to prevent topic jumpyness. We can definitely envision this at some point, and I’m more interested in making this work with your plugins than direct PRs. I’m unsure what we are going to do about locations at this point, I think having the location in the OP probably solves mosts use cases, I imagine only very few use cases need to have all the events displayed on a map so I’m unsure…
Basically, some sites may have UX issues with having the events button in the composer toolbar. Some folks will need a bigger and more prominent button, outside of the composer toolbar.
The easiest way to accomodate this kind of need is probably through a theme component. I’ve added buttons outside of the composer toolbar that successfully interact with composer markdown wizards in the past, for example this is a theme component that adds a poll builder button to the composer footer.
I’d like to be able to do the same here, ideally without the jiggery-pokery you see in that theme component, i.e. sending the whole toolbar to the composer controller so I can access it in a composer outlet.
This may be outside the scope of this project per se, however it would help us roll this out to more current events users. Perhaps I could make a PR along these lines to Discourse that allows you to do this generically, seperate from this.
Thanks for the other clarifications and notes. I’ll get back to your re locations once I’ve had more of a chance to test the interaction.
For recurring events, such as daily or weekly meetings, this could be nice and create less “topic clutter”. In other words, one topic for the meeting series, and a separate event/post for each instance that may have a unique topic/theme.
Right now we are doing this by creating a new topic for each week, e.g., “Staff Meeting 2020 W-15”, but I could imagine it’d be much cleaner if we we just had a general running “staff meeting” topic that people could respond to with meeting notes or agendas for the latest meeting. Having everything in one neat topic is especially valuable when one meeting builds on the content from the previous meeting.
This is a very exciting discussion. Thanks, @angus!
I really like the separate event title and hope it remains part of this feature. In my experience, you want to see a tightly written title for the event that shows in the calendar but a more engaging title for the topic that might even evolve through the lifecycle of an event. (e.g. “2020 Legal Empowerment Course” and “Register now for the worlds premiere leadership course taking place in December!”)