Event invites

[edwardshturman]

Event invites

Part of web platform Summer 2025 redesign

Adding a dedicated layout for each event page:

• UI with event details
  • Name
  • Thumbnail
  • Description
  • Planned activities (could be part of description)
  • Location
  • Date & time
• Collect RSVPs (going/maybe/can't go)
• Toggling whether RSVPs are required or not
• Add to calendar link(s)
• Relevant UI on /events cards. All with an invite are now clickable (+ some affordance they have an invite) and inline show quick actions

Considerations

• How does this tie in with Event recaps #12? Is the layout different; is it all on one page; if so, is the recap hoisted above the invite?
  • → Layout changes made via [...slug]/page.tsx should be kept super minimal. Likely only rendering a cover_image at the top if not null.
  • → Recaps are rendered below invites, on the same page.
• Are invites generated or expected to be enabled manually?
  • → Invite pages will be generated automatically from frontmatter. Likewise somehow for add to calendar links.
  • → Past events will be "grandfathered in" (they will have their own pages too, so long as they don't specify a link in frontmatter).
• RSVPs: related to User accounts #5? Where do they go?
  • → No RSVPs; user accounts will be tackled separately, probably alongside photo albums.

Todos

• Render event frontmatter (normally displayed on /events cards) on each event page
• Dynamically generate add to calendar links
• Affordance on /events

[edwardshturman]

One angle is splitting up the Markdown rendering from [...slug]/page.tsx into different layouts for events, community, docs, etc.

Pro: accomplishes the different layouts which we want at least for events vs. other pages, in a more idiomatic way than a bunch of conditionals within [...slug]/page.tsx

Con: larger effort; will take time to implement effectively the same layout for community & docs

[edwardshturman]

Route

Option 1 example: /events/2025-02-21/staging/invite
Option 2 example: /invite/2025-02-21/staging

Relevant considerations:

• If we go with Option 1, what does going to the base route do? Presumably render whatever Markdown is in there, or to 404/redirect if none (as is current behavior)
• How about past events and/or events with no invite? We shouldn't assume all events will have one

[edwardshturman]

Re: RSVPs... I think I may have to cave on a database/CMS over Markdown for storing events... how else will we track them?

[edwardshturman]

Decision re: RSVPs:

For big events like cascade and DEPLOY, they have their own registration systems, but for compsigh nights: ideally we could gauge e.g. how much food to get, and it'd be nice to have [an accurate number of who is going to each compsigh night], but I don't think we'd get that on any RSVP system 😂

After thinking about it and yapping with @drshooby, I think the engineering effort around RSVPs is not worth it, at least for now when I can help by doing design & branding, especially for DEPLOY. We run RSVP stuff maybe three times a semester, so I think Partiful or whatever we like for the first compsigh night, and the usual registration systems on the other platforms is fine.

Can for sure still implement event "invites" as a whole. It'd be nice if each event had its own link (which is not the case currently) that people can share with friends, add to calendar, and view the recap when it's written.