Organizers/event pages

From IndieWeb

This page tracks various efforts and discussions on how to improve the way we handle creating and maintaining web pages for IndieWeb events.

Events Issues

Event Brainstorming

Tickets and Registration

For the past several years, we've had a separate ticketing website (usually Tito) for letting people register/buy tickets to the events. We've found that having an explicit step of acquiring the ticket leads to better no-show rates. In 2016, the attendance rate of people who RSVPd from their website was 73%, vs that of people who bought a $5 ticket was 39%.

Here are the features of the registration system that have been useful.

  • Accepting payments for tickets.
  • Issuing "tickets" in a way that feels stronger than just RSVPing for the event.
  • Collecting the person's email address in order to be able to contact them before and after the event, such as sending reminders leading up to the event
  • Providing an explicit step of agreeing to the code of conduct

Other community events examples

  • WordCamps, which have many properties in common with Indiewebcamps
    • Uses (likely derived from, a TLD different from the community:
      • Philosophy: a main landing page and using subdomains for the individual events, with year/location.
      • Making itself the page for upcoming events
      • Use subdomains on for specific events
      • Issues: they had an issue with URL structure last year.
  • Mozilla Events:


Venue-specific HWC pages proposal

Proposal: Give individual meetups in individual locations individual pages, which are easier to edit and create. Automate weekly roll-ups and links in various locations. Decision to test this at 2018/Berlin/Organizers.


Aaron Parecki, Marty McGuire and Sven Knebel prepared examples:

Past ToDos

These are no longer relevant now that events live on

  • actually automate this
    • rollup pages: work in progress, running manually right now
      • support timezones for order, show for virtual (show common alternatives to?)
      • allow manually edited sections, e.g. "what to discuss!" - basically, only edit generated sections, leave others alone
    • /Events
    • Frontpage HWC box (already maintained by Kaja) needs to understand new format
    • What's Template:Homebrew_Website_Club supposed to look like now? still dayly links, pointing to section on aggregate page?
  • This should probably be open source somewhere
  • how to mark up and display virtual events
    • until now, they had p-location "Virtual Americas" or "Virtual on CET" which got copied over instead of city, which works but sounds wrong.
    • current plan: Category:Meetups/Virtual, call "Online" by default
      • how to handle multiple on same day?
    • potentially support vendor-prefixed microformats class for shorthand (p-iww-short-name, Aaron Parecki suggested p-nickname (not yet in h-event))
    • potentially accept and copy an emoji-prefix on the name
  • Error reporting?
    • extra page that gets edited with not-hidden edits provides low-key notification in IRC?
    • add notice sections to pages?
  • decide on per-city archives
  • iCal feeds?
  • ?


Mediawiki awkward for events

One of our more awkward uses of MediaWiki is using it as an events calendar.

Multiple places to update

  • Adding an event like an IndieWebCamp or Homebrew Website Club involves updating several locations
    • Home page list of events needs to be updated manually
    • Events on events are updated manually
    • IWC or HWC templates are updated manually
    • /next-iwc and /next-hwc redirects are updated manually

Creating new HWC pages is tedious

  • Copy+pasting to create new HWC pages is tedious, and is typically only done by Gregor and Tantek
  • Entering all the HTML required to format the page as an h-event is error prone

Wiki pages require manual RSVP

  • Not easily able to add new features like accepting RSVPs to the wiki pages themselves

Event pages need better presentation

  • The event pages look like wiki pages, with little visual hierarchy, and are not immediately recognizable as an event you can RSVP to to the general public

Previous Brainstorming

Events Problem Statements

  • Lots of manual work to create / update events on (most often for Homebrew Website Club, updating Events, Main_Page, and Sidebar.
  • Group event sites are hard, especially ones that take into account any particular community's needs

Events Non-goals

  • Just changing the plumbing. Just changing the plumbing has pretty much no positive (likely more negative) effect on usability. E.g. (just "let's use jekyll for that")
  • Just replace the editing UI / wiki mark-up/down syntax. E.g. the "simple web interface" benefit of jekyll is actually more complicated than the current wiki which is also a web interface. I.e. if all you're doing is replacing wiki markup with markdown, it's not a benefit. mediawiki: wiki syntax + mediawiki templates. jekyll: markdown + yaml blocks and includes. they're not actually that different.
  • "learning one more system" = worse overall UX.
  • Aspirational new system proposed by non-users of current system. The "I won't use the existing system because I hate wikis" argument is not a good argument, as absence of use of a current system provides no evidence that any new system would gain any use at all.

Events Replacement Requirements

Capturing here from IRC, some thoughts on possible requirements for any proposals to improve / replace entirety of how we create / update events on the site itself.

  • Maintenance commitment up front. Volunteers to build a new system should also consider volunteering to maintain it, otherwise it's just trading one (known) maintenance tax (updating multiple places in the wiki, annoying, but simple/easy that anyone can do it), for another (unknown) maintenance tax (updating/fixing software, likely much harder, means it doesn't get done).
  • Try and learn current system first. Volunteers to design/build/replace events should at least *try* actively updating / creating events on so that they have some direct first-person understanding of the needs of the community. Without that first-hand knowledge, any such proposal is likely ignorant of the community's actual needs.
  • Start with UI/UX sketches. Anything any of us want to build to replace the wiki events should start out with UI/UX sketches, no code at all.
  • Support your own indie events first. Group events software is so much harder / more complex than indie event / RSVP posting support (likely a superset of), that that would make a good prerequisite for any proposals/proposers.

Separate Events Site

We used for the 2016 IndieWeb Summit. The IndieWeb Summit 2016 event page was an initial attempt at creating a more friendly format for our events.

We have also set up for IndieWebCamp NYC2.

Possibilities for expanding use of a separate site for events.

  • Continue with
  • New subdomain

Some events options to consider

  • keep using for annual summits, and for specific IndieWebCamps
  • build our own minimal event interface
  • adopt an existing running project such as Calagator
  • wait for an in-progress project such as Dark Matter Eventer

Events Requirements

(not comprehensive)

  • Some level of unstructured content on event pages, so that we can allow our use of it to continue to evolve over time.
  • Be able to quickly duplicate an event rather than set up recurring events (like Calagator's "clone" function)
  • Events must support multiple locations and varying start times and timezones per location (our HWC events do this currently)

Events Ideas

  • Quickly add links to posts (notes, photos, articles) about an event
  • Highlight photos from events
    • Upload photos directly to the wiki or event page
    • By retrieving linked photos in indieweb photo posts / tweets / instagram posts
  • RSVP via Webmention like
  • RSVP directly on the page (an "I'm Going" button after you're logged in)