Move the user interface portions of this repository into the main Audimance repo

[colinbdclark]

The HTML templates, JavaScript, and CSS in this repository are now essentially the default user interface for Audimance. We should consider migrating all the performance-agnostic parts here to the audimance repository so they won't have to be duplicated for future performances (such as The Next TiMEs).

The parts that are currently performance-specific here are:

1. views/index.html, which is a plain HTML page (no server side templating) containing the audio program for Descent
2. agenda.yaml, which of course contains all the Descent-specific audio cues and spatial layout coordinates

For the first, we could consider rendering the program view from configuration, either in the agenda.yaml itself or a separate file. Alternatively, sticking with plain HTML would give a bit more room for production-specific presentations, though we'll need some mechanism (or convention) to specify to the Audimance server where to load that particular view from.

[Ulexus]

The reason for having the wrapping HTML layers was for styling and additional JS scripts to be included based on the needs of the performance. If there is an easy way to provide these otherwise, that would be great (conceivably, we could add such things to the agenda.yaml, I suppose). It is a bit weird for the end user to have to start with what is essentially boilerplate scaffolding, but I wouldn't want to lose that flexibility.

[Ulexus]

I suppose react would be a natural solution: the idea of having complete components that could be just dropped into place, with their own JS and HTML packaged together for ease of use.
I just really personally hate react and would prefer to use some more standard (WebComponent?) way of distributing it.

[colinbdclark]

Yeah, I totally agree. What we've got now is the ability for customizers to freely define their own unique user interfaces for Audimance (a very good thing), but they have to do so without being able to reuse or compose the existing UIs (not so great). In other words, they don't really have a way to say "I want my version of the Spatial Room to look like that one, but with these extra elements," aside from cutting and pasting (or forking) and modifying. There's no real path for sharing changes with others or pushing incremental improvements back upstream.

This means, currently, every unique performance presented with Audimance becomes a full customization of its user interface. As far as I can tell for TiMEs, we'll have to just fork the Descent repository (or copy some of its files into a new repository) and change the agenda and other production-specific parts of it—and be careful to keep any UI tweaks consistent between the two repositories.

I think you're right that, at some point, we need some level of UI componentization, such that customizers can create their own aggregations of the core user interface components and adapt or replace them as needed. Either that or some kind of overlay system, where you specify a directory of HTML templates, JS, and CSS that will replace/override the default ones. Or both.

I'm with you on React. I've been using Vue.js a bit these days and really like it, especially its functional reactive data flow. I think it's worth distinguishing between "standard" and "Standard"—while Web Components certainly are a W3C standard, they don't have nearly the community of practice around them as React (or others) do these days. They might be a decent fit here, though.

I guess what's most interesting to me are these two considerations:

1. How can we reduce the amount of complex tooling (build systems etc.) that we require customizers to adopt in order to make modifications to Audimance for a production?
2. What tools will allow us to keep the work of customizing the Audimance UI in the realm of plain old HTML and CSS, where a lot of non-programmers are still able to contribute effectively (not to mention the ubiquitous use of, well, automated tools that are really good at generating HTML).

Just some thoughts—again, this is probably a ticket we can tackle after the iOS release and TiMES premiere.

[Ulexus]

Agreed on all points (and I also think Vue is less objectionable than react). For the KL use case, we can take an easier path, and do have a common base, since the various shows do mostly look exactly the same and/or should be updated together. It doesn't help with Audimance in general, of course, but it would be fine here.

And keeping just three shows (Descent, Under Momentum, and Wired) in sync was bad enough; it only gets worse. So I think we should use a common set of CSS/JS/HTML for KL.