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

Send messages anywhere #1070

Open
cpvalente opened this issue Jun 12, 2024 · 2 comments
Open

Send messages anywhere #1070

cpvalente opened this issue Jun 12, 2024 · 2 comments
Labels
improvement Improvement on existing feature

Comments

@cpvalente
Copy link
Owner

Currently you can send a fullscreen message to all screens that are viewing the timer.

We would like to expand that feature, to allow users to send a message to most screen types

The UI would need to allow the user to enter a message and select from multiple possible targets.
We need to study the specifics of the design, but I suggest a list of Chips that the user can select from

messages anywhere

From a data perspective, the user would be able to target a predefined list of screens

enum ScreenTargets {
  Presenter = "presenter",
  Public = "audience",
  Backstage = "backstage",
}

In the Message Service we can modify the data to hold a message and its targets, as well as the current blink and blackout overrides

type ScreenMessage = {
  message: string;
  target: ScreenTargets[];
};

type PresenterScreenOverrides = {
  override: "blink" | "blackout";
};
@cpvalente cpvalente added the improvement Improvement on existing feature label Jun 12, 2024
@Dogo69Dog
Copy link

I would love to see this. Maybe even a 2 way communication so backstage crew can send messages to the OnTime operator.

@cpvalente
Copy link
Owner Author

Hi @Dogo69Dog , the initial proposal for messages anywhere was discussed recently and met with luke-warm enthusiasm. Also note that the proposal exaggerates its value, it would be most accurate to say "messages in public / backstage and timer screens)

In short. we couldnt come up with a (good enough) use case to want to override the contents of those screens at runtime. Maybe you have an example that would change this assumption?

As for the 2 way communication, this was part of the investigation for v3.
At the time we mentioned that entertainment tools are very well served with (often unused) communication tools. With this in mind, we decided that it was not worth introducing this to ontime

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

No branches or pull requests

2 participants