The Magical Unconference Grid Sorter

Ok people, stand back. I unfortunately wrote this up in an MS Word document, so it's more prose-heavy, and bullet-lite than most wikis are used to. However, the prose ought to flow well, and I'd love to see some commentary on this. I'm going to collect feedback on this for the next week or so, before moving forward with getting a proof of concept on the road, so put your two cents / "hey, i'd like to help" commentary in sooner than later, please. As the kids on MySpace say, hit me up -Pete

Problem:

There is this cool thing called “BarCamp” which was founded in 2005. The idea behind BarCamps (along with its cultural forebears such as FOOCamp, Open Space, and various CodeCamps that share cultural, and thus format-DNA with BarCamp) is that groups of people get together over a period of two days to discuss and present on ideas that are of interest to them, largely relating to technology, and specifically, web-based technology. The ultimate goal is to foment meaningful, rich discussion at a small group level about important topics of the day, which the community at hand has a collective interest to discuss.

The way that this typically happens, is that a given BarCamp (or BarCamp variant) has its own wiki, on which users post proposed sessions ahead of time. By the time you get to the date, there can be a lot of proposed sessions, or perhaps not. However, on the first morning, typically there is a large piece of white butcher paper, divvied up into boxes with a marker. This is “the grid.” There are as many columns as there are available rooms in which sessions can take place, and there are as many rows as there are session time slots (typically 5 .75 hour slots, or 4 1.25 hour slots, or what have you). People set to signing up in these slots for their presentations. This is one way of going about this.

Another way of going about this is to congregate on the morning of the conference, and elicit topics from people who want to present, and put them up on a white board. Once all of the sessions have been elicited, there is a discussion about the best way of allocating space and time to these sessions. Some sessions are sometimes collapsed into each other, some are tabled, and so forth. Ultimately, they are then slotted into time spots, and the conference starts.

Both approaches have downsides. The downside with the “Grid” approach is that if there are more sessions that people want to present than there are slots, the early bird gets the worm. Even if a later would-be presenter who didn’t get a slot may have been a more compelling presenter/facilitator, that never comes into play. Secondly, there is no rhyme or reason to the scheduling. Consequently, by dumb luck, topics that many people may have wanted to see separately, say, a session on User Interface, and a separate topic on AJAX, may be scheduled at the same time, much to many people’s chagrin (i.e., in my case, a Microformats session that was going to be concurrent with an Identity2.0 session—“oh shit!” was my initial reaction). Most BarCamps try to address some of these problems by making available as many presentation spaces as possible, but this simply compounds the scheduling issue.

The second approach shares some of these downsides and has some of its own. To the extent that there is actually a “public speaking” component to people proposing topics, people who are louder/more experienced may overwhelm newer/less vocal participants. This may not be a bad thing, in that newer people need an opportunity to learn with training wheels, but it does limit the presentations. At a certain point, people may stop proposing sessions, because they see that there’s no room, or think that it’s “first come first serve.” And when scheduling actually takes place, the same issue pointed up above comes into play. The point is, value is left on the table.

Software can probably ameliorate some of these problems through a combination of frictionless presentation elicitation (that is, preventing quiet/new people from getting trampled by louder people) and interest-elicitation via a voting mechanism. The frictionless session elicitation will help with getting all the potential topics of interest to people out there on the table, and the voting can help with dealing with both the “too few slots, too many presentations” problem, and also the problem of concurrently scheduled sessions of interest.

The software product below is how I propose to solve this.

Solution:

Given that BarCamps are largely tech-focused, there ought to be a way for tech to help with this problem. This is the way I see it evolving, and will describe the general workflow. Firstly, the application is web-based, in that everyone on hand has a laptop w/ a web connection. The first step is defining your playground. If the venue is space-limited, and there are only three rooms available, it is important to know that this is the case. If there is a pre-set expectation with respect to how long sessions should be, this information is set too. Once those two things are settled, the software knows how many slots it has to fill. In later editions, other limitations could perhaps be added (one that comes to mind is the availability of LCD projectors).

With the “grid” defined, we can move on to topic elicitation. In a wiki-esque capacity, or even with an administrator acting as mediator, proposed presentations are thrown up on the projected screen. Each one is logged as a separate presentation. After everyone has thrown up all the ones there are to suggest, it would probably be useful to see if there are any that can be combined, or that people are willing to combine. This is where a moderator can be helpful. Discussion about perhaps creating tracks/etc might be appropriate here.

Once the sessions that people want to present on are up there, it’s time for voting. Every user can allocate a pre-set number of “beans” to however many sessions he wants to. Everyone or even just the administrator can decide ahead of time how many beans each person should get (just one? One per time slot? 10 to make for nice weighted averages?).

Once everyone has finished voting, it’s time to filter. If there are meaningfully more proposed sessions that slots (like 30 sessions, but 10 slots), the math can get big for the software. Perhaps an initial sort by popularity could be done, and presentations above a certain threshold would be counted in the final filtering, like the top 150% of the available spaces-worth of sessions are kept for further consideration. Or perhaps all are. Or perhaps just the top 8 or 10, or however many slots there are, are kept. This is open for discussion with engineering.

Once that potential filtering takes place, the slotting takes place. The software should be able to look at all the possibilities of pairings (or triplings, or quadrupalings, depending on how many venues there are), we’ll call them “groupings,” for all the presentations. It can see what the total “beans” captured would be for a given user, for a given grouping of presentations.

That is, say a user voted 25 beans on UI and 15 on AJAX, if those two were paired together, that user’s score for that grouping would be “25”. If UI was paired with Database Design, for which that user voted 0 beans, the score would also be 25, and the 15 beans that he voted on AJAX would eventually be captured in another pairing—thereby maximizing the “beans” captured for that user, with that particular schedule.
The only time “beans” are lost, is when a user votes for sessions that are scheduled at the same time as each other. Any time there’s an “oh shit! Those are at the same time!” moment, beans are foregone.

For each grouping, the computer would run through each user and how many “beans” would be captured from him for that grouping, and see what the aggregate “score” would be for that grouping by totaling up all the bean counts for all the users for that given grouping. Then, the software would do that for every possible grouping. Once it’s done that, it should be able to find the 4, or 5, or N-time slots-worth of groupings that would maximize the total number of “beans” in play for the entire group, by minimizing conflicting sessions. Presentation groupings that found many individual users’ desired presentations coinciding with their other desired presentations (i.e., “aw shit” moments similar to the AJAX/ UI example above) would end up with lower total scores, and fall to the bottom. Groupings in which very few people would have to “miss out” on presentations they wanted to see because a more preferable one was scheduled at the same time, would rise to the top, and ultimately be settled upon.

At that point, it’s just a question of taking the n most optimal groupings that have been uncovered, and arranging them in order on the time slots, which could be done via another vote, in which users just indicated which one they want to be 1st, 2nd, 3rd, nth, by typing those numbers in, and having the computer do an average of the scores for each.

Users Profiles:

Hard core Unconference goer: Has been to these things before, and knows how to get his point across. He wouldn’t have an issue getting his session out on the grid, or making sure that there wasn’t a conflict between sessions that he wants to see. However, he would see value in a faster process that doesn’t involve hand wringing and wasted time, and being communitarian minded, would like to see the most people win. That, and he likes to avoid “aw shit” moments when there’s two cool sessions at once.

First time Unconference goer: This person hasn’t been to a BarCamp before, and though he/she is technically savvy, he may not be at home with the lack of structure at a BarCamp. In fact, because he’s not versed in the systematic intricacies of BarCamp, he may not add to the conversation to the extent that he might otherwise, because more experienced BarCampers may take the floor from him.

Reticent Unconference goer: This BarCamper may have been been to a BarCamp before, but in that he’s shy and may not be as likely to speak up and get his point across, or as much out of the weekend as he wanted. Tech savvy, but not really high EQ, or very verbal.

Unconference administrator/facilitator: Someone who has quite a bit of experience at a BarCamp, and would otherwise be up at the white board taking down notes for people, but is instead, doing it with a computer instead.

Unconference Presenter: This user has his thing he wants to present, and he really wants to make sure that he can present it, not clash with other presentations he himself wants to see, and be able to get the resources he needs for his presentation to be successful (projector).

Unconference Tourist: Mainly came to see the presentations, and to participate in them, but not to present per se. Thus, it’s probably really important for them to be able to see the ones that they would like to see. Scheduling conflicts would be particularly problematic for this user in that this the largest part of the value proposition of the Camp to him.

User Stories:

Stories for intial proof of concept:

• A user can add proposed presentations (more than one) topics to the presentation pool.
• A user can add her name to her proposed presentation
• A user can add a brief description of her proposed presentation topic.
• A user can delete her proposed presentation
• Multiple users can add proposed presentation topics to the presentation pool at once (multiple sessions) to support quick elicitation without need for an admin
• An administrator can set the number of time slots there are to be in a given day
• An administrator can set the number of venues for presentations that there are to be in a given day
• An administrator can set the number of “beans” that a given voting user can allocate amongst proposed presentations
• An administrator can “close” the session elicitation process once everyone is done.
• An administrator can “open” the voting process
• A user can allocate different amounts of “beans” to the various sessions that she wants to watch. She can allocate more to sessions she wants to badly see and fewer to those she wants to see, but less intensely.
• A user can review all the proposed sessions for a given day and get the necessary amount of information on each session before voting on which one she wants to attend
• An administrator can close voting after everyone’s done.
• An administrator can have the software run the sorting process
• Users can view the results of the sorting algorithm
• An administrator can open voting on order of groupings
• Users can indicate what order she would like to see the groupings of presentations appear.
• An administrator can close voting on ordering.
• A user can view the final scheduling

Potential later revision features:

• Once the schedule has been set, a user can pick out the presentation schedule she wants to attend himself
• A user can export the presentation schedule she has picked out himself to her calendaring solution (Palm, vCal, iCal, whatev, perhaps published w/ hCard on the page itself)
• A user can embed a permanent url for the final schedule in another website.
• An administrator can set the number of projectors there are available for use at a given time [perhaps second revision. This is a refinement]
• A user can note if her proposed presentation requires a projector this is a refinement that can go in the second revision
• A user can add linked-information to her presentation description, to give would-be attendees more info on what he plans to talk about. [this could potentially help by starting the process before people get to the conference, e.g., “campaign” and allow the presentation ecosystem to evolve over more time before the conference takes place.

So that's the spec I have laid out right now. I'd love to opportunity to dicuss with anyone who thinks that there might be value in this. Give me features that are must-haves for a first rev that I left out, and others that might be sweet for second iterations. Pete

 Create your own business wiki!Support CommunityPublic, not yet premium Privacy Policy RSS