Organizers/event pages
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 wordcamp.org (likely derived from barcamp.org), a TLD different from the community: wordpress.org
- Philosophy: a main landing page and using subdomains for the individual events, with year/location.
- Making wordcamp.org itself the page for upcoming events
- Use subdomains on wordcamp.org for specific events
- Issues: they had an issue with URL structure last year.
- Uses wordcamp.org (likely derived from barcamp.org), a TLD different from the community: wordpress.org
- Mozilla Events: https://events.mozilla.org/
Resolved
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.
2018-11-07
Aaron Parecki, Marty McGuire and Sven Knebel prepared examples:
- Instead of https://indieweb.org/events/2018-11-14-homebrew-website-club there's individual pages for events that week: Baltimore, Virtual and San Francisco.
- a weekly summary page at https://indieweb.org/events/2018-11-2nd-week-meetups
- example for a page for a past week, with images/articles: https://indieweb.org/events/2018-10-3rd-week-meetups
- new display on /Events, pointing now to individual pages (tiny hidden h-events for days with multiple events - again, the intention is to automate this)
- 2018-11-13 π¦ Homebrew Website Club Baltimore
Where: Digital Harbor Foundation, Baltimore, MD
Join us for an evening of quiet writing, wiki editing, IndieWeb demos and discussions! - 2018-11-14 IndieWeb Meetups
Where: Online, San Francisco
Join us for an evening of quiet writing, wiki editing, IndieWeb demos and discussions!
Past ToDos
These are no longer relevant now that events live on events.indieweb.org
- 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
- use Template:one-day-event for adding HWC entries when they only have one city that day
- 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?
- rollup pages: work in progress, running manually right now
- 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?
- https://www.mediawiki.org/wiki/Extension:CategoryWatch ?
done
- basic rollup pages can be generated, but manually triggered and little backend intelligence
- CSS to make "external" internal links hidden deployed globally: https://indieweb.org/wiki/index.php?oldid=53835&rcid=53704
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
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 indieweb.org (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 IndieWeb.org 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 indieweb.org 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 2016.indieweb.org 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 2016.indieweb.org/nyc2 for IndieWebCamp NYC2.
Possibilities for expanding use of a separate site for events.
- Continue with YYYY.indieweb.org
- New subdomain events.indieweb.org
Some events options to consider
- keep using YYYY.indieweb.org for annual summits, and YYYY.indieweb.org/CITYABBR 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 http://2016.indieweb.org
- RSVP directly on the page (an "I'm Going" button after you're logged in)