-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundle orientation #22
Comments
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 All in all, this is a good time to re-think the current state of channel orientation, which is not satisfactory in my opinion. |
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. |
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 ?
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.
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. |
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?
The text was updated successfully, but these errors were encountered: