Site Planning Storytime - Part 1 of X

Posted: 4/25/2020 10:46:35 AM by Chris Bass | with 0 comments
It's been pretty quiet on my end lately. Since we're in the planning phases of my next project at Wakefly, there hasn't been much in the way of technical coding going on, which is pretty much what this blog is about - so I haven't had much to write about.
‚ÄčI was talking with friends trying to figure out how best to be social at a time like this, and the problem I've been running into is that once we agree to do something it's easy to schedule (Worst case, we can use a scheduling service like Doodle to figure out everyone's availability), but actually getting folks to decide on *what* to do and *when* is the tough part, especially when dealing with disparate groups of people with their own schedules and such. 
A friend of mine mentioned he was actually already pondering a similar problem in planning smaller conventions - you have
  • a timeframe (for a convention, a weekend, for social, maybe the next week but only on weeknights, or something like that)
  • some (or in the case of an un-convention or a social gathering, none) people who are required for a given event to happen in that timeframe
  • a bunch of people who are potentially interested in a few events, but have their own availability in that timeframe
  • events may have minimums or caps on how many people can participate

and you want to maximize things like how many of the events can actually run, with the most people who are interested, in that timeframe.

With his blessing, I'm going to try to tackle this! So, this first post is largely brainstorming - I want to have to have a solid idea of what the problem is I want solved, and which cases I'm trying to support, and even more importantly, which I'm not. If we try to make something for everyone, it'll be the best tool for nobody, after all.

Initial Case Ideas

An initial list of some cases that seem to fit the model above - 

  • Folks trying to organize social events that could run in parallel, in advance - card or board games, that sort of thing.
  • Conference weekends with side-by-side events and a set of attendees and presenters
  • Folks trying to organize a serial outing, where people will be hopping in and out over the course of the timeline - a bar crawl, for example

Expanding on the Cases

Next, let's talk about the sorts of things that might apply in these scenarios.

Especially for a convention, you might want to make sure that all of the events, or some events in particular, *can* run, even if it means a suboptimal number of people attending - you wouldn't want to say "we're cancelling the main event of a conference because we can run three other panels in that time span that even more people will go to instead"... 

Taken in abstract, I'm guessing this is what convention planners are probably doing manually anyways - estimating which events will have the most people, putting those so they're not across from eachother, and making sure that as many 'slots' are filled as possible while trying to minimize how many things that the same person will go to, are at the same time.

While an algorithm to automatically put slots in place will be helpful, I also suspect that event managers will want to manually move things around, and see how it affects (potential) attendance. They may want an intro event to run earlier in the timeline, or just not want two similar events running at once, and so I want through this to consider both the 'automatic' plan as well as functionality for the managers to play around with that schedule easily.

Ruling out an Incompatible Case

For a convention, in all but the smallest of cons you probably wouldn't be able to get everyone to log their availability and interest on an app, unless you're specifically reserving slots... And unfortunately, even a representative sample stops being nearly as useful once you have min/max attendees... just because 10 out of 50 sampled can go to an event capped at 20, when you upscale and 100 out of 500 actual attendees wanted to go to that same event, that math changes significantly. I think it's clear that the sample size has to be pretty close to the actual size, for it to be useful for direct planning in that case.

However, for a small unconference, friends planning a weekend of gaming, a team deciding where to go for an outing, or a bar crawl, it seems like it could be doable to just have everyone (or most people) say 'when can you go' and 'what do you want to do'. 

We'd have to either remove the min/max attendees concept, or do some sort of upscaling of the min/max (if it's actually a 100 person minimum and we're only sampling 10%, set the sample minimum at 10)... However, the min/max concept is quite useful for smaller gatherings (maybe a board game is 2-6 players, or an event only has enough materials for 10 participants).

Because of this estimate/sample vs full participation factor, and the difference in how we consider caps/minimums, if we want to support both large conferences and small outings, we're basically building two 'algorithms'...

  • one for large conferences that assumes a poll or managerial estimates, and builds a schedule based on upscaling those results, mostly based on presumed interest without directly assigning 'people' to 'events' (except maybe as 'reservations')
  • and one that assumes everyone (or nearly everyone) has supplied their information and directly fills in slots in a schedule based on that, taking into account people's individual desires and events' minimums/caps.

The former could almost be a phase 1, on top of which the direct 'ok we don't have to estimate anymore, here's the specific interests and schedules' logic could be added later. However, thinking about that, the logic for 'we estimate roughly X people will attend, with a variety of abstracted schedules based on the polls' vs 'these specific people can attend and they have these specific schedules' seems dissimilar enough to warrant a whole separate app (or a second sub-app) for those cases. Certainly in the large-event case, it wouldn't matter if a given person updates their schedule, since it's a sample anyways. But in the small-event case, someone changing their schedule could easily make an event unrunnable, or let an event run at a better time for everyone else.

After building a small-event version, I don't know if it'd be terribly useful to 'upscale' to the estimation version, either - the algorithm would be fine, I'd just build X 'fake' users based on polls or models, and put them into the same mapping logic. But I'd want to do a lot more investigation and interviewing large-event planners before going down that route.

Therefore, I'm going to focus on the small cases. Someone with actual event-running experience can write the large-conference version, or pay me to do it :)

As far as parallel vs serial events, I don't see anything that is 'lost' in downscaling to a single event-slot (everyone doing the same thing) vs multiple slots. 

What's Next

Some things that aren't clear yet:

  • Should we actually model caps, or just minimums? Having a maximum is useful for some events, but leads to less of an 'expressing interest / availability' model and more of a 'signing people up for slots' model. Not sure how I feel about that.
  • Do we just care about 'would you go to this', or do we want to try to model participants' interest level? (5 people are okay with event A, but 4 people would *really* like event B)
  • What exactly do we want to maximize, in the 'automatic' setup? The most people, going to the most time's worth of events, or the most people going to the most total different events (if everyone likes one bar, do we just stay there all night or switch up bars even though fewer people are into it)
  • Forced events - maybe we want to force a 'lunch break' at noon, or we definitely want the big announcement at the beginning, in the main hall
  • Can events be repeated? If 50 people want to do a single event that has a smaller cap, can we run it multiple times? And if so, can people say they want to do it once vs multiple times?
  • Can attendees update their schedule as their availability or interests change? 
  • Can attendees see their updated schedule before everyone's filled out their data? It means a lot more recalculation, but means they can see 'tentative' results (that are, until the end, probably pretty misleading...)
    • I liked this plan initially, but if they can see their updated schedule and also adjust things, it becomes gameable -  "oh, I see that if I say I 'only' want to do Event A and can only go at X time, then it happens when I want it to.".. Also we have to deal with 'I expressed interest in Event A, saw I was in it, and now I'm out because other people wanted it and it got moved to a new time for them'
  • What sort of notifications do we do? Things like 'hey the schedule is ready' or 'hey, the available options changed, want to go update your interests?' 

Sanity Check

A final check before I think about this more - based on what I've already said, is this a thing that already exists (in part or in whole) somewhere else?
  • Any spreadsheet or survey/polls app, can be enough for just 'hey, who has interest in a set of activities',
  • Doodle/StrawPoll/zvite all can do the 'for a single event, pick a time' better than I'll be likely to manage...
  • Sched does the 'Attendees choosing things they want to go to, and managing their schedules' very well, but it assumes a static 'plan' set in advance. It doesn't have any pre-schedule functionality.
What we're really targetting here is 'collect interest and availability for a set of activities, define when those activities can happen, and then schedule the set of events to all fit in that block, with the most attendance, based on participants' responses'. And I'm not seeing that anywhere.

So, I'm going to mull on some of these unclear points for a bit, talk to some folks, see if there's more to add onto this before I get started!
Comments
Blog post currently doesn't have any comments.
 Security code