Support Graphics Data Definition (GDD)

[from-the-river-to-the-sea]

Graphics Data Definition (or GDD for short) is a system wherein a portable graphic defines its controls in a platform-agnostic way. I think NodeCG should support it.

What does that mean? Let's break it down:

"portable graphic"

This is a graphic that exists as a standalone set of files. It could all be bundled into one HTML file, or it could be an HTML file with other files next to it that are referenced by the HTML. The key point is that it runs with no dependencies on other applications. Just open it in your browser, execute the appropriate commands, and you've got graphics. This is a common format used by CasparCG, though it is not the only format compatible with CasparCG. For instance, current NodeCG graphics work fine in CasparCG.

The way these portable graphics work in CasparCG is that they define a simple API in the global scope that CasparCG knows to look for and use. This API consists of just a few methods like window.play(data), window.update(data), and window.stop().

controls

The UI used to operate a graphic. In the case of CasparCG, this is almost always a custom client made bespoke for the graphics in question. To be honest, there's a lot of duplicated work on this front in the CasparCG scene and I think they'd benefit from using NodeCG more but that's just me talking.

What GDD proposes is that a graphic ships with a JSON Schema file that describes all the data that this graphic operates on. A UI is then automatically generated from this schema. Will it be as good and compact and pretty as a hand-authored bespoke UI? No. Will it be faster and easier? Hell yeah it will. That's the tradeoff. Most importantly: it will be good enough to operate and operators will probably still be happy with it. If they aren't, that's when you either refactor the schema to change the UI or you decide to take matters into your own hands and make a custom UI for that graphic. Ideally, this would never happen because the pre-made GDD components would be so thoughtfully made that people would just be happy with them.

"platform-agnostic"

Not talking about Windows, macOS, or Linux here. I'm talking about NodeCG, CasparCG, your in-house graphics system that is basically NodeCG but which you've invested too much pride into and therefore you keep using and developing it instead of switching to a common platform that would benefit everyone but hey that's your business and not mine, etc. GDD flips the script and says "instead of the UI being coded for the platform, we instead code the data schema for the graphic and let the platform generate the UI. Each platform can go about this how it pleases so long as it doesn't violate the specification."

NodeCG support for GDD

What would NodeCG support for GDD look like? Well, it would look like a user dropping a GDD-compatible graphic (and its associated files, if any) into their graphics folder and that's it. They wouldn't even need to add them to the graphics stanza in their package.json. Literally drag and drop and you're done. We can extract all the necessary data from the GDD schema and the filename or foldername. A dashboard panel would be automatically generated for each GDD graphic. In the short-term, this would suffer from all the drawbacks that the current panel arrangement system has. In the future, if we implement something like React Mosaic, this UX would improve.

Interop

Supporting GDD means we get interop with other tools. For example, Loopic is a WYSIWYG editor for broadcast graphics that outputs CasparCG-compatible HTML. If Loopic supported GDD, these graphics could be used in NodeCG by just dropping them into the graphics folder.

As of right now, the only tool I'm aware of that supports GDD is SuperConductor. We'd be part of a push to encourage adoption of GDD in more software.

Limitations of GDD

GDD does not help use cases where data from external sources needs to be used, such as an API that an extension talks to and relays to a NodeCG graphic. Such things would still need to be hooked up with NodeCG's APIs, and make the graphic no longer be portable. It could perhaps still use a mix of GDD and non-GDD UI though, if need be.

[Hoishin]

I love the idea of defining schema to populate dashboard. It has limitation but does a great job of doing basic stuff.

• I'm a bit confused about CasperCG and GDD. Does CasperCG support GDD or Casper has basically the same idea of portable graphics? Is GDD a superset of the format that Casper supports?
• If we decide to do this inside NodeCG core, the HTML files should be placed in a completely new folder IMO because it defines both graphics and dashboard.
• I'm honestly not sure about putting this into the core until it's more widely used (even the referenced spec repo says it's a draft). I think this is doable with a dedicated bundle then see how the format goes?

[from-the-river-to-the-sea]

I'm a bit confused about CasperCG and GDD. Does CasperCG support GDD or Casper has basically the same idea of portable graphics? Is GDD a superset of the format that Casper supports?

So, it's a bit weird because CasparCG server by itself is just a renderer and doesn't know or care about GDD. Where GDD comes into play is in the clients used to control CasparCG. There is a first-party CasparCG client but it is ancient and nobody uses it. The way that first-party client worked was you just had a key-value table that you punched data into. That was how you controlled graphics. You had to memorize all the possible keys for each graphic and what kinds of values they took. This poor UX is where the desire for GDD arose from. Adoption of GDD in Caspar land is more about getting people to use a client that supports it, rather than Caspar itself adding some kind of support for it. There is no action required on Caspar's end.

If we decide to do this inside NodeCG core, the HTML files should be placed in a completely new folder IMO because it defines both graphics and dashboard.

I'm okay with that.

I'm honestly not sure about putting this into the core until it's more widely used (even the referenced spec repo says it's a draft). I think this is doable with a dedicated bundle then see how the format goes?

You're right that this could probably be a bundle first and then if it proves itself worthy it could become part of core. I like that idea. Hedges our bets a little.

[from-the-river-to-the-sea]

Update for completeness: there is a part of Caspar that knows about GDD and that is the Media Scanner. It's the bit that tells clients "here's what media I have that is available for you to play". When the Media Scanner picks up an HTML file, it will check it for a GDD and parse/report that schema as part of its response.