Thoughts on hosting an IndieWebCamp Pop-up Session

Thoughts on hosting an IndieWebCamp Pop-up Session
A few weeks back, I hosted a stand alone IndieWebCamp pop-up session. I had promised to scribble down some thoughts about the process and how it might be improved based on my experience. If anyone else has thoughts on how it went or how future events like this could be improved, I’d love to read them.

With traditional in-person two day camps on hold for the foreseeable future as the result of the coronavirus, doing some smaller one day or even one session topics seemed like a good idea at the time. After having done it once, I now think they’re an even better idea. A variety of things came out of the experience that I wouldn’t have anticipated.


I posted the notice for the event to my website and to about two weeks in advance. This helped give me enough time to invite about 15 people I expected to be interested in the particular topic. A few tweets as reminders helped in addition to the announcement being early enough to make it into two of the IndieWeb newsletters.

I held the session at 10am Pacific so that we might be able to draw people from the late evening time zones in Europe, mid-afternoon people on the East coast of the U.S. but still late enough in the morning so that people on the West coast of America wouldn’t have to be up too early. This seems to have worked out well though I feel bad that we did likely shortchange several people in India, Asia, and Australia who might have attended.

I expected that I would be starting out small and simple and honestly only expected about 3-6 people to show up. I was initially thinking a tiny, one-topic Homebrew Website Club, but on a weekend.

On the day of the event my guess was that we had about 25 attendees, but statistics after the fact showed that 35 people logged into the session. There were still people arriving into the room at the two hour mark! According to the numbers, there have already been 210+ views of the archived video since it was posted later on the day of the event.

I suppose that future sessions will give additional data to bear the hypothesis out, but one of the side-benefits of having a specific topic announced a few weeks in advance seemed to have brought in a large number of people interested in the particular topic and who were generally unaware of the IndieWeb as a group or a movement. I’ve seen several of these people at subsequent Homebrew Website Club meetups, so using these sessions to help spread the principles of IndieWeb does seem to have been generally useful. About half of the attendees hadn’t been to an IndieWeb event previously. I did try to start with a brief introduction to IndieWeb at the start of the session and offered some follow up at the end, but I probably could have planned for this better.

I wish I had collected people’s emails, but I’ll have to do this manually somehow if we do so now. The traditional signup and organization structure for full camps would have done this, but it would be nice to have a simple workflow for doing this on a lower key basis for pop-ups. Emails would also have helped to put together a post-event questionnaire to potentially create a follow up session.

Thanks certainly goes to all the people who have built pre-existing infrastructure and patterns for pulling off such an event so easily.

Wiki Infrastructure

Since the session, I’ve gone into the IndieWeb wiki and created a stub pseudo-IndieWebCamp listing to help make organizing future stand-alone pop-up sessions a bit easier (particularly for documenting the results after-the-fact.)

The key is to make doing these as easy as possible from an organization standpoint. Having pre-existing pages on the wiki seems to help a lot (or at least feels like it from a mental baggage perspective).

Here are the relevant pages:


One of the things that was generally missing from the program was some of the hallway chatter and getting-to-know-you preliminary conversation. I think if I were doing another session I’d schedule 15 minutes of preliminary chat and dedicate about 30 minutes of introduction time into the process and encourage people to have a cup of coffee or drink to help make the atmosphere a bit more casual and conversational.

On thing that surprised me was that despite scheduling about an hours’ worth of time to the session we still had a sizeable crowd talking about the topic nearly two hours later. I think having more than just the traditional hour of conversation at a camp was awesome. It helped us not only dig in a bit deeper into the topic, but also helped in managing things given the larger number of attendees over the usual camp setting where 5-15 session attendees has been the norm. Doing it again, I might outline a three hour mini-event to allow covering a bit more material but still keeping things small and relatively casual.

I certainly benefited by the presence of a few old hands in the IndieWeb community showing up and helping out on the day of, particularly in terms of helping to manage Zoom infrastructure and format. A single person could certainly plan and execute a pop-up session, but I would highly recommend that at least two people show up to co-host on the day of the event, especially if the attendance goes over 10 people. 

The IndieWeb Zoom set up prevents organizers from allowing users to share their screens during a session. (This issue has popped up in a few HWCs lately too.)  This was potentially helpful in the earlier days when it was easier for zoombombers to pop into rooms and disrupt a conversation. There have been enough changes to Zoom with precautions built in that this part of the lock down probably isn’t needed any longer, particularly given how useful screen sharing can be.

Despite having many places to indicate RSVP’s I had very little indication of how many would show up. Something to improve this would be nice in the future, though isn’t necessarily mission critical.

I’ve definitely experienced the organizer decompression time required after putting together something big. I feel like there was less of the traditional post-event stress for this one session which allowed me to focus more of my time and attention after-the-fact on the content of the session and getting some work relating to it done. For me at least, I consider this a big personal win.

Create day/time

Traditional camps set aside day two for people to create something related to the session(s) they attended on day one. We didn’t do that for this session ahead of time, but I desperately wish we had created a better space for doing that somehow. Later on the afternoon of the session, I posted a note encouraging people to write, create, or do something tangible. I wish I had created a specific time for either the following day (or even a week later) for everyone to reconvene and do a short demo session as a follow up.

Simply having a blog section and demo page on the wiki did help encourage people to write, blog, and continue thinking and working on the session topic afterwards.


One of the things I’ve appreciated since the session is the level of conversation in the general IndieWeb chat rooms, on people’s blogs, and peppered around Twitter and Mastodon. Often when couched into a larger IndieWebCamp there are so many sessions and conversations, the individual topics can seem to be lost in all the hubbub. Fifteen sessions concentrated on one weekend is incredibly invigorating, but because all of the concentration was on just a single topic, there was a lot more focus and energy spent on just that one thing. I sort of feel like this concentration has helped to carry over in the intervening time because I haven’t been as distracted by the thirty other competing things I’d like to work on with respect to my website since.

There has been a lot of specific article writing about this one session as some camps get in entirety.

Perhaps pop-up sessions on broader topics and problems that haven’t had as much work or which have only one or two small examples may benefit from this sort of concentrated work by several people.

I do wonder what may have happened if we had had a broad conversation about the top level topic for an hour and a half and then broken into smaller groups for 45 minutes to talk about sub-topics?


In the end, the session went far better than I ever expected for the amount of time I invested into it. I definitely encourage others to try to put together similar sessions. They’re simple and easy enough to be organized by one person and they can be carried out by one person, though I’d recommend two.

I encourage others to suggest topics and set up other sessions.

Even if you’re not interested in the organization portion, why not propose a topic? Perhaps someone else with a more organizational bent will come along and help you make it happen?

I’m happy, as always, to help people plan them out and deal with some of the logistics (Zoom, Etherpad, wiki, etc.) should anyone need it.

What session topic(s) will you propose for the next one?

This post was originally published on Chris Aldrich

Thoughts on Wikity for WordPress

I spun up a new instance of Wikity today at to test it out for potential use as a personal online wiki. My goal was also to test out how it may or may not work with IndieWeb-based WordPress pieces too.

Below are my initial thoughts and problems.

The /home/ page has a lot of errors and warnings. (Never a good sign.)

It took me a few minutes to figure out where the Wik-it! bookmarklet button was hiding. Ideally it would have been in the start card that described how the bookmarklet would work (in addition to its original spot).

The Wikity theme seems to have some issues when using for http vs. https.

  • Less seems to work out of the box with https
  • The main card for entering “Name of Concept or Data” didn’t work at all under https. It only showed the title and wouldn’t save. Switching to http seemed to fix it and show the editor bar.

I’ve tried copying over from Aaron DavisWikity instance, but the cardbox seems to fail on my end.

  • Nothing seemed to work at all when I had my site as https. In fact, it redirected to a URL that seemed like it wanted to run update.php for some bizarre reason.
  • On http I at least get a card saying that the process failed.
    • Not sure what may be causing this.
    • Doesn’t seem to matter how many cards it is.
    • Perhaps it’s the fact that Aaron’s site is https? I notice that his checkbox export functionality duplicates his entire URL including the https:// within the export box which seems to automatically prepend http://
    • Copying to my own wiki seems to vaguely work using http, but failed on https.

Multiple * in the markdown editor functionality within WordPress doesn’t seem to format the way I’d expect.

Sadly, the original site is down, but the theme still includes a link to it front and center on my website.

The home screen quick new card has some wonky CSS that off centers it.

Toggling full screen editing mode in new cards from the home screen makes them too big and obscures the UI making things unusable.

The primary multi-card home display doesn’t work well with markup the way the individual posts do.

The custom theme seems to be hiding some of the IndieWeb pieces. It may also be hampering the issuance of webmention as I tried sending one to myself and it only showed up as a pingback. It didn’t feel worth the effort to give the system a full IndieWeb test drive beyond this.

Doing this set up as a theme and leveraging posts seems like a very odd choice. From my reading, Mike Caulfield was relatively new to WordPress development when he made this. Even if he was an intermediate developer, he should be proud of his effort, including his attention to some minute bits of UI that others wouldn’t have considered. To make this a more ubiquitous solution, it may have been a better choice to create it as a plugin, do a custom post type for wiki cards and create a separate section of the database for them instead of trying to leverage posts. This way it could have been installed on any pre-existing WordPress install and the user could choose their own favorite theme and still have a wiki built into it. In this incarnation it’s really only meant to be installed on a fresh stand-alone site.

I only used the Classic Editor and didn’t even open up the Gutenberg box of worms in any of my tests.


The Wikity theme hasn’t been maintained in four years and it looks like it’s going to take quite a bit of work (or a complete refactoring) to make it operate the way I’d want it to. Given the general conceptualization it may make much more sense to try to find a better maintained solution for a wiki.

The overarching idea of what he was trying to accomplish, particularly within the education space and the OER space, was awesome. I would love nothing more than to have wiki-like functionality built into my personal WordPress website, particularly if I could have different presentations for the two sides but still maintain public/private versions of pieces and still have site-wide tagging and search. Having the ability to port data from site to site is a particularly awesome idea.

Is anyone actively still using it? I’d love to hear others’ thoughts about problems/issues they’ve seen. Is it still working for you as expected? Is it worth upgrading the broken bits? Is it worth refactoring into a standalone plugin?

This post was originally published on Chris Aldrich