📅 An event is a type of post that in addition to a post name (event title) has a start datetime (likely end datetime), and a location.
For information on IndieWebCamp events themselves, see:
Why publish indie events
You should post events on your own site to own your events and so your friends with indieweb sites can directly RSVP to you (as well as post invitations to others) without depending on a silo to mediate your event related interactions.
Why POSSE events
How to markup
Event posts must be marked up with h-event.
Optionally they can be wrapped in an h-entry as well (though it's not clear this is necessary). Parsers should be prepared to handle events without an h-entry tag.
(sample event post markup with a top level
How to provide an RSVP UI
Event posts should have webaction buttons for RSVP actions and inviting others. E.g.
See Facebook's RSVP UI:
How to accept RSVPs
How to accept invitations
In implementation order:
Ben Werdmuller uses idno on werd.io to post events since 2013-06-25 (right after IndieWebCamp 2013!), which automatically accept RSVPs from other sites using RSVP webmentions. Events may also be replied to in the same manner as notes and articles. E.g.
Bret Comnes has implemented events inside of jekyll for bret.io since 2013-07-25. It supports receiving webmentions, but does not parse responses for RSVP status or display reply contexts at the moment. Example:
The event data is stored in the YAML which separates the final layout and the event data. A form is used to assist in creating the event post via prose.io.
Jeena Paradies has implemented events on his website because he wanted to host HWC:s and it wouldn't look good without the possibility to RSVP to a indie event. The event page receives RSVP:s and displays them under the event. Example:
gRegor Morrill added event posts (sans RSVP) on 2015-10-01. Example:
The following people either strongly want to implement events on their site, or are in the process of doing so, you may find some implementation clues in their notes
Tantek Çelik: event posts are a pretty big itch for me, but also a lot of specific work:
As ideas here are implemented, they should be moved to actual sections of their own with links to examples.
Typical silos event posts (e.g. Facebook, Google+) provide (encourage) the option of an event image - used as a header for the event. This header is used at the top of the event permalink page, and also often shown in an event list view (e.g. on Facebook).
Such header images are often quite a good visual/emotional draw for the event. Header images are typically representative of the event, sometimes displayed with the name of the event superimposed on top.
If you're posting events, consider providing this option for yourself (in your event posting UI or otherwise as part of your publishing system) as part of your indieweb event posts as well.
Since the photo would be deliberately chosen and associated with the event, we could extend h-event to represent the photo as well with:
In particular, on event posts, the location is shown *first* as a centered dot in a wide and short rectangle map that shows the local area, and then second underneath as text address.
Showing a map and showing it early is both visually striking and instantly provides a sense of "is this near me", or "is this near somewhere I'd like to be or might be anyway". It quickly gives you context in a way that a purely textual address does not.
A horizontal map (banner map?) from a Facebook event:
There are two typical existing approaches to displaying RSVPs:
Clusters are typically displayed as facepiles, either entirely, or abbreviated at some fixed number with a method to expand / view the whole set.
Time order presentation usually include some text about the RSVP, e.g. "is going", "is attending"
Every event silo by default shows who else is has RSVPed that yes they're going, and more so, often first display who you know that's going to the event. Quickly seeing "who else is going" or might go or is invited is a huge sense of context/comfort as well, especially with little face icons.
E.g. Facebook clusters (potential) attendees by:
(and declined is typically hidden)
More screenshots needed
Event attendees on Facebook:
Note the going/maybe/invited sections on FB first show *only* those you know (if any), and *only if* there's no one you know in a section, does the section show 5 icons of others who said they're going/maybe or were invited. In either case, the order of icons is most recently responded/invited first.
Public events don't necessarily have a public list of invited users, depending on the system, but nonetheless list attendees. For example, on Plancast:
Plancast only shows invitees on an event to the event organizer, i.e. when the event organizer themselves is looking at the event permalink page.
Main article: invitation
People like being explicitly invited to events. One way to send invitations with indieweb events is:
The idea is that a person's site's webmentions queue sees webmentions from the event to the home page and interprets that as an invitation to the event. If needed we could add some markup like
Also see indieweb messaging, which also uses a webmention to the user's homepage.
How and where should event posts be POSSEd?
Event-aware destinations to consider:
Problematic event-aware destinations:
See also: RSVP: POSSE
Indieweb sites with event posts (and perhaps even just RSVP posts) could also provide an index of what events they're attending, e.g.
From a human design perspective this makes sense as:
which is likely a union of personal event posts and RSVP yes (and maybe maybes too?) posts.
Kind of like a view of your public calendar of events, regardless of whether you're organizing/hosting or just attending.
Such an events index could be displayed as a list view (similar to the default view of fb.com/events) or as a calendar view (like gCal), or with an option to toggle between them.
An easily-discoverable link should probably be displayed from the user's index or homepage.
Markup for an h-event on a site must include a number of properties to enable presentation and user interaction as implied by some of the above brainstorming, and some of the better silo UX as documented in "Silo Examples"
The following fields/properties are necessary in the markup somewhere:
Response context CRUD
Similar to the general reply context: CRUD protocol, when an event changes (name, location, times, description, etc.) you should send webmentions to all the responses to the event that you've accepted, e.g. to all:
What about when an event is cancelled? Options:
Here is what the 2014-02-27 redesign (limited rollout as of that date, but subsequently broadly rolled out) looks like:
This was perhaps the pinnacle of Facebook's event page design.
Facebook has had one of the more interesting/nicer/cleaner event page designs for quite some time.