iframe / Vimeo cell interaction with set

[fjenett]

Active cells might need some ways to interact with the set, for example report back that they are "done" (playing).

Update, here's what this issue means:

• message (postmessanger.s) from set to cell to tell it to "start"
• message from set to cell to tell it to "stop"
• message that cell is about to be deactivated
• message from cell to set that it became active
• message from cell to set that it "started"
• message from cell to set that it "stopped"

Note that this is not about how sets create and handle cells, which should be outlined here soon: https://github.com/motionbank/score-system-frontend/wiki/Lifetime-of-a-cell

[mlewisosu]

The conversation over in issue 5 has drifted over to this topic of cell/set interaction, so I'll write about it here.
(tell me if you want this in a different thread)

Can all cell types (including iframes) be made to initially load with a poster image (with your rollover title/text behavior)?

Then when ANY cell is clicked, ALL other cells go back to their poster-image-with-rollover state (like Deb Hay cells).
This would be the default behavior...

BUT: could you then add an option which, when activated, would make it so a given cell ignores go-back-to-poster messages from other cells, so that e.g. two movies could be run comparatively. That is, these cells would start out in poster image, but once clicked/activated, would stay activated, regardless of other cells being activated.

(Presumably they would return to poster if scrolled off screen then back into view)

[fjenett]

Yes that is what i'm thinking too. The only problem i see is that there is no way to deactivate a cell then (except for scrolling). Would that be OK for you?

[mlewisosu]

There would be no way to go back to poster image/rollover, true.

We assume Vimeo cells could be stopped by pressing their pause buttons.
(e.g. given a subset with multiple Vimeo cells with the ignore-back-to-poster option on, the user could run as many or as few as they wanted via vimeo play/pause controls)

Our D3 and Unity content would need to handle stop/pause functionality through their own interfaces.

We're ok with that in the situation where we explicitly turn on the option for "this cell ignores go-back-to-poster broadcast messages".

[fjenett]

OK, perfect!

I think i can implement a message that will let cells know they should stop / start (become invisible / visible) that would allow for some better behaviour on the iframe front. D3 and Unity could then just pause their render loops for example ... and maybe show that they are paused.

[fjenett]

... fully implement in the future.

[fjenett]

Leaving this open for the future ..