Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track background colors for events #234

Open
johnjohndoe opened this issue Jan 12, 2024 · 3 comments
Open

Track background colors for events #234

johnjohndoe opened this issue Jan 12, 2024 · 3 comments

Comments

@johnjohndoe
Copy link
Contributor

johnjohndoe commented Jan 12, 2024

Context

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

Screenshot of the "Room occupation by track" page

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:

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
Copy link
Contributor Author

@cbeyls, @Wilm0r fyi

@johanvdw
Copy link
Member

johanvdw commented Jan 13, 2024

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
Copy link
Contributor Author

johnjohndoe commented Jan 13, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants