I’ve been to several conferences and conventions at this point, ranging from small 1-day anime cons run by students to unconferences of 100 people to regular academic conferences of a few hundred people to mega-conventions of tens of thousands of people booking entire Las Vegas hotels like DEF CON.

And whether run poorly or well, I think they have all struggled with the basics of how to present and update a schedule, despite sometimes quite elaborate investments. (The DEF CON convention schedule & website being especially impressive.) A Google Docs spreadsheet and an overwhelming chat channel (WhatsApp/Signal/Discord) doesn’t cut the mustard: as attendees move around or talks relocate, or you go back and forth from the spreadsheet to the cryptic room numberings, it’s easy to get lost. They all have struck me as pounding a square peg into a round hole—none of them have seemed like the obviously correct way to ‘turn a conference into software’.

It occurs to me after reading Said Achmiz’s posts about the (usually bad) design of “virtual tabletops” (VTTs), that a VTT might be a good convention/conference organizing UI/UX metaphor. That is, a convention/conference is surprisingly like a D&D tabletop roleplaying game: you have the player characters (attendees) who are collaborating to tell a story (network, talk, do stuff) together where they are constantly moving around (crawling the dungeon) but the overall layout is generally static and known (the conference building is pre-built, the dungeon map is pre-generated usually), and you have a dungeon master (organizers) in charge, who is organizing pre-planned but highly fluid events.

A VTT is basically “collaborative MS Paint”, that you can use to play tabletop roleplaying games… but on the Information Superhighway.

You have little markers you (or the administrator) move around, you have a 2D image (usually raster but SVG is required for large levels) as a background for your graffiti, you have some way to chat with your fellow collaborators, and that’s about it, fundamentally. It’s intuitive and easy to understand: “what you see is what you get”.

The players crowdsource the worldbuilding by telling a story together and just agreeing to pretend. It is intrinsically “situated software”, customized to each session as a “home-cooked app”. You could “boil the ocean” to spend billions of dollars to develop an AAA video game which model the entire world and support every possible game situation and which can accurately track hundreds of characters and spells and show you what happens if you fireball a crowd of orcs and simulate out detailed damage calculations and collapsing bodies (one of them twitching indefinitely because the physics engine doesn’t quite handle floating-point round-off, also, it crashes at 257 orcs)… or a human can just say, “your dice roll was high enough. All the orcs are dead.” and use a little eraser to remove a bunch of green circles from the current drawing in MS Paint. Different implementation, but same result.

A conference is similar. So many conference needs can be implemented ‘for free’ just by people using the VTT map in a natural fashion, adopting ad hoc design patterns: just draw on the map! Want to know who’s in a room? Just draw on the map!

That works well for handling ongoing things. But what about future room uses? Much of the difficulty in a con is just deciding which future events you should go to. The present map only shows you the present, not the future (nor the past). You can handle ‘the past’ by simply recording the tabletop session and replaying it (all changes are recorded as a log and just played back, similar to a video game recording).

You can handle ‘the future’, by doing the same thing, just that the ‘video’ is now editable (because it has not yet actually happened). So you see the present slice of the ‘video’ by default, and you can scroll up or down. When you look at a future slice, like the slice labeled “3:30PM Saturday XYZ”, you can edit it to ‘put down Mr ABC’s token in Room 5 giving the talk “On Chicken Sexing”’, say, and if Mr ABC has to cancel, just go back and erase it. And the Labels × Time can be viewed/edited as a 2D spreadsheet. (Because the map/location doesn’t change.) This lets attendees view either a convenient abstract representation, or a spatially-grounded one: you can either drill down to a specific time/place/event, or you can roll forward the projected conference and say ‘oh good, that session will be right next door to my previous session, no need to rush’.

So, with this map where you can scroll back and forth in time, how do we run a conference?

• You could invest in tens of thousands of dollars of overpriced glitchy gadgets to track people around, or ask people to install a definitely-not-spyware app to report their current GPS coordinates to the conference organizers, or just not have any idea where anyone is…

  Or you could just have a mobile-friendly web page (which they always keep open so the WiFi dropping isn’t a big deal), which shows a 2D map of the conference center and little headshot-photo/name icons which people drag-and-drop when they happen to open it up to check something and notice an out-of-date bit of data, taking half a second to update someone else’s location. (“The Famous Guest has been spotted walking to the garden. Updating token location.” “Ack.”)

  This is much less creepy than an app secretly constantly phoning home, and has advantages like plausible deniability or control over how much granularity or visibility there is into someone’s movements; if someone doesn’t like it, they can delete their token entirely. (It may sound like a lot of work, but drag-and-drop takes a second, and if everyone does 1 occasionally, it’s hardly any work at all for each attendee to keep the map accurate; the organizers, acting as the dungeon master, keep it tidy.)

• You could invest in complicated e-boards or posters, or you could just label each room on the map sensibly with its current purpose and occupants.

• You could have some complicated ‘suggestion box’ or remote buttons or a blizzard of direct-messages overloading the conference organizers…

  you could just have attendees scribble on the map next to the bathroom: “warning out of toilet paper DO NOT USE”, and then the organizers erase it once a gopher has dealt with the critical shortage.

• You could go around yelling at people “dinner is about to start in the main tent, please proceed there now” or investing in big networked loudspeakers to cover the entire campus, or you could just draw a bunch of big red arrows on the map: “→ !DINNER NOW! ←”.

  (And because a lot of coordination is being done on the map, the official channel notifications become more useful, and announcements there become viable, rather than drowned out by minor updates.)

• You could have some complicated export and edit function in your all-singing-all-dancing conference app, or people could just scribble on the map, take a screenshot, undo the scribble, and send it to a friend.

• You could have a lost-and-found office, or you could just draw each item on the map where it currently is and let people remember ‘oh yeah, I left my laptop in the corner of that room’; or if you want a formal lost-and-found spot, create it with a little pile of crudely drawn icons or thumbnail-photos.

• You could have a fancy poll widget, or you could just have people write on the map “Chicken for lunch? 0 vs 0” and people increment the count to vote, or “Session on X in Y?” and people drag their token into the session to vote for it and see how many will be there.

  This applies to future sessions as easily as present sessions—one could have everyone scroll through the future and vote on each time-slice.

• You could have a survey interface, or people could just type text on the map next to a session afterwards, it gets erased when the next session starts up, and everyone rewinds the history if they want to look at the feedback on a particular session.

  This also handles photos/videos: upload them immediately to the map when/where, erase as new ones happen, people can rewind through the history to view & save. Since everyone is using the history view for other things, they will know those are there and preserved indefinitely, and not worry about ‘deletion’.

• You could have some sort of ‘planned sessions’ or users could just draw little dotted lines with question marks about where they might go in each time-slice.

• You could have big posters labeling designated spots to talk about “X” or you could just let people label spots on the map “warning this is where the AI nerds talk”.

• You could have some fancy affiliation system, or people could just color their tokens—the Google guys are all a specific shade of blue, and so on.

• You could have a Q&A queue system or a chat channel that questions get lost in, or people can just type on the map and the moderator erase bad or answered ones as they go.

• You could try to have some sort of meeting scheduling system to set aside a room to talk with someone else, or you could just draw 2 lines from their token and your token to an empty room, and everyone else will see that meeting spot will be occupied soon and avoid it.

• …

All of this emerges naturally if you just give attendees a useful set of primitives and trust them to collaborate—which is why they are there, after all. (If someone doesn’t cooperate, they can be disciplined, shamed in front of their peers, or in the last resort, asked to leave.)

After a critical mass of users, the map becomes indispensable and everyone will use it voluntarily.

With this metaphor, you can handle various organizing tasks easily. There can be access controls so only DMs see certain things, which could be useful for tracking staff (“where the hell is John‽ oh, he’s out at the campsite fixing the toilet?”), possibly fine-grained to allow separate sections of the conference—the organizers of one ‘track’ do not necessarily have any reason to interfere with another track. Sometimes one might want privacy, and then a game’s ‘fog of war’ is potentially useful (eg. private sessions or dinners or workshops might want to not reveal all the players in that room, and so become off-limits except to the whitelisted attendees). Good design for UI/UX like this is usually iterative, so I won’t try to speculate too much about what one would want to add.

And then, of course, you can have a physical tabletop. Nothing stops you from having a physical one corresponding to the digital one. Having a few big monitors displaying the VTT live in key locations is an obvious thing to do, but you could be more imaginative. A big magnetic board with little fridge-style magnets or a table with a built-in monitor for fancy graphics (eg. Arkenforge), or you could make a fullblown 3D physical diorama of the location, and label little circular tokens, or print out photos and tape them to a token, or go crazy and print out little 3D caricature figurines! I understand that diorama people sometimes do kinds of projections onto tabletop setups to animate them or do various “special effects”, which could be useful (little live video streams from each room…?). It would be a lot of fun to walk by a table and see how the little figurines have been moving about, as art imitates life.

As far as I know, no one runs a conference like this. The closest examples I know of are in various kinds of disaster response where people do ad hoc coordination using tools like Google Maps to drop pins where there’s currently some bottled water, that sort of thing. There is also Gather.town, which I understand is pretty successful for purely-online conferences/meetings, and adopts an isometric 2D perspective much like a VTT.

But there are already various VTTs or multiplayer MS Paint-like web pages, so a conference could experiment cheaply with this by adding it onto their existing approach: start with the simplest thing that could work to see if the basic idea appeals to attendees, and they do things like mark up the map with little observations and updates, and then that can justify someone implementing more elaborate features like creating a bidirectional spreadsheet view etc.