Track background colors for events

[johnjohndoe]

Context

The "Room occupation by track" page shows tracks in various colors as shown in the following screenshot:

The FOSDEM Schedule app for Android aims to match these colors to allow users to feel familiar and to quickly identify tracks when switching between the website and the mobile app.

Request for clarification

From an earlier conversation I understood that colors for each track are randomly assigned at each generation of the HTML schedule. Please correct me if I misunderstood.
I found the following references in code:

• website/config.yaml

  Lines 50 to 55 in dee495c

  	# Colors to use for events and tracks in various grids.
  	# These are a combination of two sets of colors from colorlovers.com,
  	# namely the following:
  	# https://www.colourlovers.com/palette/2510621/NARANJA
  	# https://www.colourlovers.com/palette/92095/Giant_Goldfish
  	colors: '69D2E7 A7DBD8 E0E4CC F38630 FA6900 EA813D E7A350 FCC777 C3DBB9 A79474'

• https://github.com/FOSDEM/website/blob/dee495ca8c64551e45212051905e47059bfb002a/content/schedule/roomtracks.html#L88C1-L93

If the above is correct, the question arises: Can we have a stable mapping for colors by track names? A stable mapping is needed because track names and colors are hardcoded in the app. The publication of the app happens days or weeks before the conference hence changes to the mapping cannot be reflected without updating the app. This process takes too long to actually reach users in a timely manner.

[johnjohndoe]

@cbeyls, @Wilm0r fyi

[johanvdw]

Your analysis seems correct.

As part of a solution I think we could store track colors in pretalx (it is in already) and export them to yaml when building the website.

The major issue I see is that when tracks are added, eg when the main track is split into different tracks (see eg https://archive.fosdem.org/2020/schedule/ ) we may still need to adjust the codes, to make sure we don't have similar colors next to each other.

Also we have too many tracks for every track to have a unique color, so having them assigned based on building/room order is probably not such a bad idea. Technically it would mean that we can only assign colors once we have assigned tracks to rooms.

Another thing, looking at the current table, the community devroom which runs over two days has two different colors.

[johnjohndoe]

Thank you for your feedback.

Thinking about it now I believe the obvious solution which does not require the client(s) to fetch colors at runtime would be to share the exact same deterministic algorithm within the website generator and the client(s). I believe the order of input and the color palette are essential.

Algorithm draft

To ensure consistent colors for the same devroom on both days and not the same color next to each other we can

1. store each color by room pair in a lookup structure (sorted by room display order) and
2. let the color algorithm interate one step if the same color has already been assigned to the last room.

These checks have to be part of the algorithm of course.

I suggest we write down and document the algorithm in pseudo code independent from the programming language. What do you think?