I Built an Interactive Schedule for my Field's Largest Conference (and yours, too)

At some point in time, I have published an article on this website in which I said something to the essence of “academia runs on spite.” I don’t remember if I wrote that I run on spite, or my entire industry. But someone does. And when it comes to conferences, this is even more true.

A few months ago, I was asked by a professor at my department whether I would be interested in helping organize the largest conference of my field, the International Conference on Computational Social Science (IC2S2). Of course, I said yes.¹ Since I’m the IT guy at the department, it fell onto me to create the website. However, another task that already dawned upon me was one that no one else was thinking of at that point: we would have to come up with a clever way to design an interactive schedule for the conference, because organizing several hundred people across four days will yield a maze of program points that people will have to navigate.

What I came up with after some weeks of engineering work was Conferia.js, an interactive schedule tool that respects organizers’ time and gives participants a clear schedule to never get lost amid dozens of sessions and keynotes. In this article, I want to share with you why I wrote this tool, how I did so, and how you can use it for any conference going forward to prepare an easy interactive and feature-rich schedule.

The Problem: Scheduling for Large Conferences

Let us begin with the problem that this tool solves: scheduling for large conferences. It all begins with the insight that, as the size of a conference grows, so does its need for a powerful tool to navigate the event. IC2S2 2025 is such an event. The conference features many hundred participants that will visit Norrköping over the course of four days with 10 tutorials, 9 keynotes, hundreds of posters, and 290 accepted presentations sorted into 48 parallel sessions of 6 talks each across 8 rooms and 3 days. As you can see: the conference is really big, and as such having no agenda would be very bad. One would still be able to somehow navigate the participants through the keynotes, since those are scheduled sequentially. But how are participants supposed to decide on which of the eight concurrent sessions they want to visit? And doing so six times (two parallel slots times three days)?

A common sight at many large conferences is an interactive agenda which lets participants quickly see the entire schedule at a glance, search for keywords and sessions. Maybe, it even lets participants create their own, personal agenda so that they can already weed out things they are not interested in before the conference even starts.

While small conferences and workshops usually do not have an interactive agenda, and do fine, this doesn’t work here. And indeed, IC2S2 is a great showcase for the various approaches organizers can choose to follow:

• IC2S2 2022 at the University of Chicago decided to go with a simple, non-interactive PDF program.
• IC2S2 2023 at the University of Copenhagen implemented a fully custom web app for the interactive agenda.
• IC2S2 2024 at the University of Philadelphia opted for an Excel solution.

Now, all of these solutions have benefits and drawbacks. The most traditional solution is certainly the PDF program created by the organizers of IC2S2 2022. It is easy to understand, and the obvious choice in case someone decides to distribute printed programs. However, as you can imagine, this approach only gets you this far. IC2S2 2022 was significantly smaller than IC2S2 2025 will be. But even then, the program has almost 50 pages, and it contains no abstracts. So either the authors did a great job at conveying their idea in the title, or participants are out of luck if they want some help deciding. This is certainly not perfect.

The next-best job was done by the organizers of IC2S2 2024. Using embedded Excel spreadsheets is certainly a … choice, but it does convey the sense of which sessions are in parallel much better than a purely sequential PDF file. I do enjoy this solution somewhat, because it really smashes the ugly reality that most of the world runs on Excel into your face unfiltered. But obviously, it comes with drawbacks: Navigating those sheets can be cumbersome, and they are lacking obvious convenience functions such as a search function. Also, while Excel is powerful, free-form cells only get you this far when it comes to time-based grids, even though Excel assumes anything to be a date.

The — in my humble opinion — best solution thus far has been implemented for IC2S2 2023, courtesy of the amazing Laura Alessandretti. She² has built a fully custom solution to actually deliver a web app designed to present the full program of the conference for maximum convenience. IC2S2 2023 was also the first IC2S2 that I attended, and as such, I was very pleased with the ability to check the program both before and during the conference. There was only one problem: It was a hard-coded solution. At least I could not find any library in there, and the corresponding JavaScript code looked very custom. This means that it only worked for IC2S2 2023, and only for the very … peculiar data format they chose. I commend the organizers for taking the time to develop an interactive agenda, because it clearly pays off. But I can also fully understand many other organizers opting for less ideal solutions.

Because here’s the main problem conference organizers face: It’s a small team of highly motivated but essentially volunteering individuals against a flood of equally motivated researchers who all want a spot in the program. Every minute of work time is reserved months in advance, and so it is crucial to shave off as much overhead as possible. The less work, the better. Organizing a conference has to be very efficient. This is one of the central lessons I learned during my time in the conference chair team.

The problem, in short, is that conference organizers have little time, and there are no good one-size-fits-all solutions that organizers can adopt for offering an interactive agenda to their participants that does not add an unwieldy burden on the organizers.

Requirements: Identify what needs to be done

After having identified the problem — no reusable framework for displaying interactive agendas —, the next step involves the requirements the proposed solution has to meet. Essentially, it has to balance two contradicting requirements:

1. The organizers need to spend as little time as possible on the program creation, as there are many other tasks. Any solution for an interactive agenda therefore must add as little overhead to the already overfilled to-do lists as possible. Otherwise, the “interactive” part of the agenda becomes a low priority, creating a detrimental experience for everyone.
2. The participants, on the other hand, have a vested interest in such an interactive agenda, because without it, navigating a large conference is a pain. I speak from experience here. My first large conference was the DGS-conference (German Sociological Association) 2016 in Bamberg. The available app was very thinly advertised, so I stuck to the unwieldy PDF program.

Any solution to an interactive agenda, in other words, needs to balance these two needs. The obvious solution was something that slots right into what organizers need to do anyhow (creating some big Excel spreadsheet), and transform this into an interactive agenda automagically. After some thinking (and decent experience of both good and bad agendas), I came up with the following requirements that translate the two needs identified above into actionable points:

• Every program planning process will result in an Excel spreadsheet, with one event per line, usually sorted into keynotes, parallel sessions, and special events (e.g., conference dinners). The solution must essentially work on top of one of these spreadsheets.
• It should work without any big IT knowledge. It should be possible for a researcher in the arts and humanities to implement the solution with a little bit of googling and fiddling. It should not require IT expertise.
• It should work with any type of program layout, that is, both conferences with entirely linear programs, parallel sessions, or (most likely) both. It should accommodate whichever assortment of events there are. It should work for any conference there is.
• It should work on both desktop and mobile, since participants will likely use it on their computer (before) and phones (during the conference).
• It should not require any additional software, since one-time use apps are generally not nice for participants. But every phone and computer has a browser installed.
• Changes to the schedule should be easy to make.
• The tool should have zero additional dependencies. It should be a single, minified JavaScript file that can be easily included by the conference organizers.

This should cover what the app should do. But it’s a lot. It requires a lot of the tool to be this flexible and work for any type of conference. However, we luckily do not live in a vacuum, and so we can make some assumptions that we can work with.

Assumptions: What we can work with

If we would not make any assumptions, anything short of a literal magic box would take years to be developed. And, indeed, there are some proprietary companies that offer conference program scheduling. Those products usually do not assume anything and will work with only an Excel spreadsheet. The problem? They do assume one crucial thing, and that is money. And anyone who has visited an academic conference at least once in their life knows that this is an optimistic assumption to make.

So, what can we assume, given the constraints? Thinking a bit about the way conferences are organized (again, this requires some participation and behind-the-scenes knowledge of conferences), we can make a few assumptions:

• The conference will have a web presence. Or, if it doesn’t have a dedicated website, such as IC2S2, the university typically has some website on which conference organizers can get a small sub-page for their conference. Worst case, GitHub Pages is becoming more common among academics of any couleur.
• The organizers will utilize Excel (or an alternative) to produce the schedule.
• On each conference, there are only so many types of events, so we can hard code those.
• There will be at least one person with a somewhat comfortable handling of code such as HTML or JavaScript. So the app can require a bit of code (as long as it’s reasonable and well-documented).
• As long as it is a one-time effort, we can assume the organizers to be happy to spend a bit of additional time implementing the solution, so it does not have to be a completely drag-and-drop solution.

This now concludes the preparatory part of the planning. Next is deciding on the actual implementation.

Implementation: The Tech Stack

If you’re less interested in the technicalities of the app, you can skip to the last section: The Test Case: IC2S2 2025.

For implementing Conferia, I chose to go with a somewhat modern, relatively basic tech stack. I wanted to keep the solution small (because bandwidth is still an issue in many places), and also not overcomplicate it. Here’s what and why I chose:

• Classic HTML/CSS/JavaScript stack: Since I don’t want any complex app solutions, it should run on any device. And the only technology that runs on any device is a simple web app, because every device has a browser.
• TypeScript: For the actual language, I chose TypeScript. I could have done this all in vanilla JavaScript, but I have learned over the past years that the added type safety is so much more efficient, because it completely obliterates the need to debug which types you are shoving around in the app.
• Rollup.js for bundling: This is a somewhat odd (for me) choice, because I’ve been socialized to the web with Webpack. However, Webpack is kind of a destroyer type ship, while this project requires more like a light littoral cruiser. Also, Marijn Haverbeke (CodeMirror) speaks very fondly of it, so I decided to give it a go. It’s an insanely light-weight solution to the problem.

That’s it. If you’re somewhat familiar with web development you may wonder about the many omissions. So here’s what I decided to omit, and why:

• No framework; no Vue/React/Angular. This is because the app should be very simple. There’s not much state-management involved, and the little that is I can handle with a bit of JavaScript myself. This is the biggest size-saving measure of the entire endeavor.
• No CSS/SASS/UI framework. The app should live off of the styles present on the site, and otherwise come with a very limited default design. Simplicity is king, because there is so much information already flying around.
• No Papaparse or CSV framework to speak of. This was less a decision I made willingly, but merely due to the fact that Rollup unfortunately can’t properly bundle Papaparse, and CSV loading frameworks in the JavaScript ecosystem are surprisingly rare. And I wanted it to have zero dependencies.

Implementation: How it Works (Technically)

Finally, how it works. I will introduce to you only how it works technically, because the actual documentation on how you can use it for your conference is well described here.

Before I start, let me once again acknowledge two people that have inspired this work a lot, and which have ensured that I didn’t have to re-invent the wheel: Laura Alessandretti, who has created the IC2S2 2023 schedule, and Carl Nordlund (IAS), who has also created an interactive schedule, but for the NSA Conference 2024 (Nordic Sociological Association, not what you’re thinking of).

So let’s dig into the code. The main entry is the big Conferia class. It handles data loading, DOM setup, and rendering. One initializes Conferia simply by calling new Conferia(/* options */). That’s it. Everything else is handled by the library. What it will do first is generate its DOM structure (using the various helpers in the dom folder) and mount it into the document. Then, it adds a few event listeners that handle interactions with the tool. Then, it immediately begins loading the CSV file.

The CSV parser is, as mentioned, not some proven library, but instead a very rudimentary parser that probably breaks with grossly malformed CSV files. It takes in a string of CSV file data, and returns a set of events (CSVRecord) that contain all events part of the conference. It happily accepts CSV files with any number of columns, but it does require a set of columns that I have identified to be absolutely necessary:

• date_start and date_end should contain ISO 8601-compatible time stamps that denote the start and end of the event.
• type: Can be one of session_presentation (for individual presentations), keynote, meta, single, and special. Most of these events are actually interchangeable, and because these are mere semantics for the library, nothing prevents you from defining all your keynotes as simple “single” events, or coffee breaks as “keynotes.” (However, in some instances, these events do matter, such as the detail dialogs.)
• title, abstract, author, location, and chair contain exactly what the names say – the various pieces of information for the events.
• session and session_order are required for session presentations. They identify the session several presentations are part of, and their order. The CSV parser uses this information to group all presentations into a single session event that share the same session name.

Additional properties are fine, and can be used to modify the simple parsed records that the library produces using the rowParser utility function. Also, it turns out that for both Excel and Google Spreadsheets, ISO 8601 seem to be difficult, so I added a dateParser function that allows you to quickly transform all the date columns into something that the date library — luxon — can work with. I figured this is simpler than manually correcting all the errors Google made to my spreadsheets.

Armed with this loaded data, the main class then proceeds to render the entire UI in one humongous updateUI function. This function runs every time there has been a change to the internal state. There are not much of those – adding and removing items from the personal agenda, toggling between viewing all events or just the personal agenda, and filtering.

Whenever the function is called, it will determine the date and time range of the currently visible events (first and last day, earliest and latest time) which define the x- and y-axes of the time grid. It will then calculate a bunch of additional information, such as the amount of pixels per second based on some configuration values and what the actual records look like. Also, it calculates room conflicts, that is, which rooms need to be displayed in their own column for each day. (Rooms with no conflicts are always displayed column-spanning.)

Next, the function updates the time and day gutters at the top and left side of the app, as well as the background grid. The latter is simply a repeating CSS gradient pattern, because adding all those grid lines as individual elements would’ve transformed especially older phones into stove tops.

After that is all done, it will actually display the events. Using the various pieces of information, it calculates the left and top offset for each event from the origin in the top-left. The left offset, as well as the width of the event, are dependent on whether it is a conflicting event (= there need to be other events displayed next to it). Then, it applies a height based on the duration of the event and the calculated pixels per second. At the very end, it adds a set of day dividers so that it is easier to distinguish between parallel events on the same day, and the next day.

Now, there are some performance penalties because the entire DOM is being re-rendered all the time. One could now argue that this is precisely the reason for which there are frameworks such as Vue and React, but I have figured out that since the library is very targeted in its functionality, it is an acceptable overhead. And indeed, on my old smartphone, the entire schedule still rendered appropriately fast. I will get to optimizing this if necessary.

One final aspect I haven’t yet gotten to is another class that manages a different part of the state: The Agenda. This is basically just a rudimentary store that reads the contents of the local storage of the browser upon page load, and stores personal agenda items in it. This means that users can add and remove events from their personal schedules and rest assured that – as long as they don’t clear their browser data – the information will remain across page loads and even computer restarts.

However, this doesn’t help once conference participants leave their computer and actually go to the conference and view the schedule on their phones. This is where a utility function comes in, that lives in util/ical.ts. This is a function that generates valid iCalendar files based on the schedule. That allows participants to first create their personal schedule, and then add it to their calendars. I didn’t use a library for this because, again, the iCalendar format is actually quite simple, and this has a very specific use-case. I implemented the bare minimum of RFC 2445 and RFC 5545, and called it a day. And it works very well.

Some Notes: Caveats and Oddities

As with most projects, I felt that I learned a lot while implementing this tool. For example, I once again improved my knowledge of timezones, because for conferences, this actually becomes a problem. See, oftentimes, we researchers travel across many timezones to visit conferences across the world. This then means that the dates we see in our local calendars are actually at a different time from the local one of the conference venue. The interesting part here is that the conference schedule itself should always display the local times, even for participants in a different timezone, because this is what will be relevant to the participants once on location. However, if they decide to add the events to their calendar, they need to have them in their correct timezone, because the events are relative to all other events they store.

Another fun part to figure out is that, even though the iCalendar format is relatively simple, it’s not when it comes to timezones. Effectively, you have two options: Either provide all events in UTC, or have fun manually defining all timezones you need. I absolutely opted for the first option, because there was no way I would actually enumerate all existing timezones, as we all know from Tom Scott that this is futile. This ended up going against the preferred practices of luxon, the date time library, resulting in me commenting the conversion function with “Do violence to ISO 8601 datetimes.”

Speaking of datetimes: It was very interesting to implement the various helper functions to manage the needs of the library, and think about how that actually works. For some, such as getting the earliest day or the latest day, there were built-in helper functions, but for others, such as getShortestInterval, I had to come up with sometimes odd contraptions. Also, it turns out that luxon is unable to perform calculations solely on times alone, it always requires a date. On the upshot, luxon does a good job at string-representations, since I was able to use built-in JavaScript operators such as > and < to compare datetimes to determine if an event has a conflict.

Aside from timezone difficulties, the iCalendar format really showed me how old it actually is. RFC 2445 is from 1998, and its update, RFC 5545 from 2009 sticks to most of the old conventions. While trying to get the utility function to spit out valid ical files, I discovered some … interesting choices. First, they recommend never exceeding 75 octets. If a line gets more than 75 octets long, you should employ what they call “line folding,” which essentially means to split up the line, but prepend each following line with a space character to indicate to the parser that that is actually part of the previous line. What is an octet, you ask? Well, it’s a byte. In 1998, this usually corresponded to a single character, but in times of UTF-8 this is no longer true. An emoji, for example, is often two bytes (octets), sometimes longer. And with grapheme clusters, this gets even more difficult. So I decided to roughly stick to 70 characters (after all, it was a suggestion, not a hard requirement) and do the little silly dance for them. To wrap up the iCalendar oddities, line breaks in summaries were possible, but had to consist of the literal characters “\“ and “n,” and not, as I had thought, newline characters. Finally, lines required to be delimited by CRLF (carriage return, line feed), instead of any valid line separator. Now that I think about it, I may write an article about this, too!

Lastly, some notes on the DOM part. Since I decided against using a framework for the DOM handling, I had to rely on the built-in methods such as document.createElement to handle everything. This means that the DOM code is actually the most verbose part of the code base, but at the same time I am very happy with the progress that has been made on semantic elements in the past years. For example, the event detail modals are implemented using dialog elements which essentially come with a lot of JavaScript functionality already attached, so it was relatively benign. The only remaining issue I have with the DOM part is that state and DOM is somewhat separated, and it showed me very vividly why modern frameworks such as Vue and React exist: Properly managing state and DOM updates is indeed hard, and I ended up spreading state management a bit too far across the code base. I will be fixing this at some point, but this goes to show how valuable frameworks are in keeping our brains sane.

The Test Case: IC2S2 2025

Let me finish this article with a few words on the first test case for which I have developed Conferia.js: IC2S2 2025 in Norrköping. It turns out that I made the right decision in developing the tool. First, I have never explicitly communicated what format I want the schedule in, I only requested a schedule so that I can turn it into my data. And, lo and behold, it came to me in the form of a large Excel spreadsheet. Especially nice was that all sessions were already properly ordered. This means that within about a single day (less if the OpenReview API hadn’t been such a chore to work with) I could take a large Excel spreadsheet with almost 300 presentations and turn it into the required data format for Conferia. Also, it turns out that whatever I did with the CSV parser, it worked flawlessly in parsing the CSV file with no additional work on my side.

Adding the tool into the website was just as simple and easy as I have expected it to be, and all in all, the biggest time-consuming factor of the conference schedule creation was simply the creation of the schedule itself. The interactive agenda was up and running from zero to hero in about a single work day — something I believe many conference organizers would be willing to spend for a proper agenda. In addition, updating the conference agenda is extremely straight forward: Edit the Google Spreadsheet, re-download the CSV file from it, and upload that one to the website.

So, in case you’re in the hot seat of a conference at some point, I would be happy if I could convince you that this tool might be worth a shot! All you need to know is outlined in the organizer’s guide on the manual. If you end up using it, please send me a message!

Until then, happy conferencing!

¹ My advisor would like to let you know that he thinks that this was an overcommitment, and the more time passes, the more I agree. But I digress.
² After scouring the website’s source code, I have concluded that she seems to be the author, since a few files are hosted on her website, but I cannot be entirely certain.