search

UCL-INGI / ICTV

ICTV is a simple content management system for digital signage on multiple screens.
Other
15 stars 5 forks source link

Bundle orientation #22

Open Drumor opened 5 years ago

Drumor commented 5 years ago

As I first implement in #21, I thought it is a good idea to extend orientation of a channel to a bundle. This allows user to subscribe their vertical screen to a bundle that contains all the vertical channels for example. Does it make sense?

mpiraux commented 5 years ago

If I recall correctly, verticality is only defined for channels that use the editor plugin through one of its channel parameters. So currently it's a parameter of the editor plugin.

In the long term, we should investigate whether all templates can have a vertical counter-part that matches their purpose. Then we can avoid this orientation problem in the channels. Of course some edge cases will never be satisfying, e.g. a horizontal picture cannot be adequately displayed in a vertical screen.

In the short term, I think it makes sense to generalise the handling of orientation to all plugins. Currently, the editor plugin will restrict the templates available to known templates that work in both orientations. This should not be dealt with by the plugin, but by the ICTV core. When invoked for a vertical channel, a plugin would get a reduced list of available templates and be able to know if it is in vertical mode. Then I think it has all the tools to work properly.

Then we can add orientation to the Channel class as a common attribute of all channels, much like the subscription right for example. Orientation being part of all channels, we can avoid all the hacky checks. Vertical screens will only be able to subscribe to vertical channels, vertical bundles will only be able to contain vertical channels. New edge cases appear, such as what if a vertical channel changes its orientation regarding the bundles it is contained in and the screens that are subscribed to ?

All in all, this is a good time to re-think the current state of channel orientation, which is not satisfactory in my opinion.

31416r commented 5 years ago

This implies to push the screen orientation at the channel level. Is this the right choice ?

In most cases (if not all), the information that is uploaded is not specifically "oriented". I mean that people want to transfer the information to their reader and do not generally care about the screen orientation. I think that it is not a good idea to push screen orientation on the users by multiplying channels that would basically display the same information (ex. AREC landscape and AREC portrait).

Woulnd't be better to allow the plugins to produce 2 "versions" of the slides into a channel : horizontal and vertical. For example, a vertical screen registered to such a "mixed" channel would then only receive the slides having a vertical "version".

This requires more changes but is, in my opinion, a better choice.

mpiraux commented 5 years ago

In most cases (if not all), the information that is uploaded is not specifically "oriented".

I do lack of deployment experience, so any feedback on this is welcomed. From what I can see near my office, most of the content is produced by automated plugins, for which indeed orientation is not an issue. Some other screens are mostly displaying images that are uploaded manually. How many of them are there ? And what is the projected growth ? We have to think to those use cases as well.

I think that it is not a good idea to push screen orientation on the users by multiplying channels that would basically display the same information (ex. AREC landscape and AREC portrait).

I do agree, but we have to deal with the current state in which orientation is not really satisfactory. Being a editor-specific parameter, we can't come up with a good solution to filter channels in bundles.

Woulnd't be better to allow the plugins to produce 2 "versions" of the slides into a channel : horizontal and vertical. For example, a vertical screen registered to such a "mixed" channel would then only receive the slides having a vertical "version".

That is close to the long-term vision explained above I believe. I came up with the short-term one in the case that we need to address this issue rapidly. Otherwise I would be more in favor of the long-term one of course.

Also, we can transition from the short term to the long term solution rapidly. Once all templates have a vertical variant, we can remove the per-channel orientation parameter and set it dynamically based on the screen that needs to be rendered.