Recent & UpcomingResources |
rsvp(Redirected from RSVP)
💌 This article is a stub. You can help the IndieWebCamp wiki by expanding it.
WhyWhy implement RSVP posts? Own your RSVPs! It’s empowering being able to RSVP (especially yes or maybe) from your own site to the indie event posts, and via Bridgy Publish to Facebook events as well! Share your RSVPs with friends. For public events that you'd like your friends to attend, post RSVPs publicly on your own site. When your friends see that you're going or might go, it helps encourage them to also attend. Encourage friends to go even if you cannot. Why implement and post a RSVP no? A public RSVP no is a good way to share and promote an event you wish you could go to but can't make it to. Why POSSE RSVPs? Because the sharing / encouraging aspect of publishing makes sense beyond the simple RSVP answers, it also makes sense to POSSE all your RSVPs as you would any other reply or note (e.g. to Twitter etc.) beyond just responding to the event. How toHow tos for RSVPs are very similar to the how tos for replies so we won't duplicate common info here. Publish an RSVPPost a reply and use the h-entry
Possible RSVP values: yes, no, maybe, interested Send a webmention to the event post as you would for a reply to any post. See reply#Make_a_comment for more general details on posting replies. You can copy and paste this into a post, and replace the example URL with the URL of the event you're RSVPing to. If your blog software already wraps your posts with h-entry, then you can copy only the inside text. <div class="h-entry"> RSVP <span class="p-rsvp">yes</span> to <a href="http://example.com/event" class="u-in-reply-to">IndieWeb Example Event</a> </div>
Multi RSVPIf there are multiple copies of a single event (e.g. POSSE copies, or reposts), you can post a multi-RSVP, a single RSVP post that replies simultaneously to multiple event URLs. Publish a multi-RSVP just as it says above, and add in-reply-to markup for each of the events, similar to how a multi-reply does so to multiple posts. The difference is:
NEEDED: (a complete multi-RSVP markup example would be nice too) Update an RSVPSimilarly, update your RSVP and send another webmention. See reply#Update_a_comment for more general details on updating replies. Delete an RSVPSimilarly, delete your RSVP, send another webmention, and be prepared to return 410 GONE for your RSVP permalink. See reply#Delete_a_comment for more general details on deleting replies. IndieWeb ExamplesIn datetime order of implementation (earliest first) Ben Werdmuller
RSVP posts are marked up with the Example: Bret Comnes
RSVP posts are marked up with the Example:
Aaron Parecki
RSVP posts are marked up with the Example: Multi-RSVPs published since 2014-09-08. E.g.
autosuggestIf a p3k user is creating a reply to a URL, p3k:
Nick Doty
Example: Tantek
RSVP posts' reply-contexts are marked up with the Examples:
Multi-RSVPs published since 2014-09-12. E.g.
Kyle Mahan
gRegor Morrill
Jeena
Example: TimTemplate:webrocker implemented RSVP notes on his site www.webrocker.de since 2016-04-16 Example:
Shane Becker
BrainstormingRSVP buttonsAn RSVP post starts with some UI to create it, typically in the context of a specific event. RSVP Interested GoingA reader could recognize an event post, and present buttons for the user to RSVP (e.g. via micropub with their own site). Good start with minimal likely options: [ Interested ] [ Going ] Clicking either button would publish the respective RSVP to the user's site via micropub, and at a minimum could then:
RSVP simple updatesA reader that implemented the above [ Interested ] [ Going ] buttons could add just a tiny bit of browser-only code that allowed for undo and updates, as follows: Start with minimal likely options again: [ Interested ] [ Going ] But this time, if the user clicks a button, only that button turns into static text, e.g.: If the user clicks Interested: ✓ Interested [ Going ] If the user clicks Going: [ Interested ] ✓ Going If the user clicks on the static text with checkmark ✓, then delete the RSVP and show: [ Interested ] [ Going ] Similarly, if the user clicks on another button after clicking one, then update the RSVP accordingly and switch the display to that button being static checkmark UI text. RSVP buttons with stateIf a reader can keep track of the posts it has made on behalf of the user (keep a cache of the user's RSVP post permalink), then it could update the buttons accordingly (instead of just showing static UI text). If they chose "Interested", show a button drop down[ ✓ Interested v ]which when clicked shows: [ Going ] [ ✓ Interested ] [ -------------- ] [ Not Interested ]If they chose "Going", show a button drop down [ ✓ Going v ]which when clicked [ ✓ Going ] [ Maybe ] [ ---------- ] [ Not Going ] And if they click any of those, the show Going as above, and: If they chose "Not Interested", delete the RSVP post and show (like before) [ Interested ] [ Going ]If they chose "Maybe", show a button drop down [ ✓ Maybe v ]which when clicked [ Going ] [ ✓ Maybe ] [ ---------- ] [ Not Going ]If they chose "Not Going", update the RSVP post and show a button drop down [ ✓ Not Going v ]which when clicked [ Going ] [ Maybe ] [ ---------- ] [ ✓ Not Going ] And again, when selected, update the RSVP post and show the updated button/dropdown. Text DesignSimilar to like brainstorming, it's useful to explore how to best represent RSVP posts as a notification (e.g. to the author of the event (and the invitation) that the RSVP is responding to), text only (e.g. SMS authoring/output or POSSEing to text only destinations), inline hypertext and markup for that. (stub) E.g. some p-rsvp value/prose equivalent possibilities to consider:
Remote variants? Only for some level of actual participation (yes, maybe).
POSSEHow and where should RSVP posts be POSSEd? Event-aware destinations to consider:
Problematic event-aware destinations:
Other destinations:
Capacity and TicketingTODO( If event capacity is limited, the event host may not know at the time of responding to the RSVP whether you are allowed in (get a ticket) or not (waitlisted). It can supply a URL to answer this later in the RSVP 202 response. However this protocol could be extended to cover the ticketing case too.
Attendees can also RSVP for multiple people, ie request multiple tickets, by posting multiple RSVPs, one per ticket. CMSes can automate this with custom RSVP UIs that generate and send an RSVP post per ticket. During the event, there are a couple possible ways for host(s) to verify attendees. If you want to use traditional tickets, when the RSVP poster goes to the ticket link, they can authenticate in with indieauth to get the actual ticket proof, which may be printable, a QR code to display on the phone, or just a page you show to the doorkeeper. A more modern, IndieWeb way is to forego tickets entirely, digital or otherwise. If the host has followed the process above, they end up with a list of RSVPs and domains for those RSVPs. The host can then set up a page on their site that accepts IndieAuth logins. When an attendee arrives, they IndieAuth into that page with their domain, the host checks the domain against their RSVP list, and lets them in (along with any guests). Silo ExamplesFacebook has fairly widespread support of RSVP posts and RSVP-specific webactions on event posts. Many details about Facebook's RSVP posts and buttons (including screenshots and wireframes) are captured here: See also
|
Thank you to our sponsors of IndieWebCamp events!
