Description
An annotation may have the "activating" motivation. Activating can be thought of as a generalization of "linking"
as used for hot spots in 2d -- it asserts that when any of the bodies of the annotation is activated
(clicked, tapped, looked at long enough, verbalized, whatever) then the target is "activated".
In Scenes, the bodies are always annotations, but can be painting, commenting, supplementing or any other
motivation.
The target can be anything that is activatable. Currently defined:
- A specific resource with an AnimationSelector, meaning trigger the animation.
- An annotation that paints a Camera, meaning move the viewpoint to that Camera.
(Other things could be a FunctionalitySelector, to trigger Play/Pause/Stop/Fastforward/etc on AV)
For example, a commenting annotation as the body and a camera as the target would mean that a user clicking
on the comment would swap to the camera's viewpoint. Clicking on a model painted into the scene could
trigger an animation on that model to play.
This is coupled with two additional properties on "activating" annotations, both of which have a list of
annotation or annotation page URIs as their value.
enables: For each annotation in the value, remove the 'hidden' behavior if it has it.disables: For each annotation in the value, add the 'hidden' behavior if it does not have it.
Hidden resources cannot be active or activated.
Chaining together activating annotations can then allow the implementation of, at least:
- Specific camera position to look at an Annotation
- Multi-step linear stories
- Animations, including as part of stories without disrupting the flow, and looping animations (they activate themselves)
- Interactive components such as light switches (enable/disable a light), jukeboxes (enable/disable Audio Emitter)
What this (and the precursor toggles) cannot do:
- Change properties or apply transforms. E.g. you cannot click a pawn to move it forward one square on the chess board. But you could hide it and show the same model at a different place. You can't change the color of a light, but you can hide that light and show another one of the color you want.
- Bring in new resources from outside the manifest a priori, as they trigger off of annotations that must already exist to have the 'enables'. However the URI of the annotation page could be external and a client could read it in, e.g. to have a user interaction bring in transcription / captioning / whatever annotations that aren't loaded by default. Here there would be no target, as nothing is activated, just annotations being enabled. In comparison, an external contentState could define whatever it wanted to, if we allow full "editing" functionality.
I think with this approach we get the useful 90% that we got with the contentState approach, without reduced complexity.