Include control panel configlet to define global configurations

[hvelarde]

Cycle2 is really powerful as it can be seen in the demos.

We must define a standard set of configurations that can be applied to slideshows created using Cycle2; among them we want to include things like a default template that could be stored in Plone's registry and used by other packages using this add-on.

AFAIK, currently the following packages will use this add-on:

• collective.nitf: A Dexterity-based content type inspired on the News Industry Text Format specification.
• sc.photogallery: A Photo Gallery content type with a slideshow view.
• covertile.cycle2: A carousel tile for collective.cover based on the Cycle2 slideshow plugin for jQuery.

the following is a list of features/definitions to be used in this add-on; the configlet should provide a way to store/modify them:

• an option should be provided to define the default image size to be used in slides
• by default, slideshows must run manually on user request, but an option should be provided for auto-running and a pause-on-hover should be enable in that case
• an option should be provided to define the default transition effect
• an option should be provided to define the default timeout for transitions
• by default, slides must be centered
• by default, slideshows must use captions
• an option should be provided to define the default caption template
• by default, slideshows must use pagers
• an option should be provided to define the default pager template
• by default, slideshows must use progressive image loading
• by default, slideshows must be enabled to use swipe gesture

[hvelarde]

@agnogueira @djowett @fredvd @mauritsvanrees @rodfersou comments please!

did I forgot something?

[rodfersou]

@hvelarde I don't like the idea of progressive image loading in 2 aspects: 1) need an inline script 2) makes more requests (and it is not good for mobile devices)

Maybe the pager and caption position could be another option (top / bottom / left / right)?

@hvelarde I don't wanna start a flame war here, but did you see this plugin http://www.idangero.us/swiper ?

[hvelarde]

@rodfersou we already decided to use Cycle2; we can review this decision in a year or two but we can't be changing every couple of weeks as it costs time, effort and money.

[djowett]

I think this could be useful, though pt urgent from my point of view. You might want to prioritize that list, rather than trying to do it all at once.

The default image size would be most useful to me - and I would like that option to allow image sizes other than only those provided through the plone.app.imaging list (icon, thumbnail, etc.) many of which are not really useful for a carousel

[hvelarde]

@rodfersou regarding your first concern, as @polyester mentioned before inline scripts are not evil per se; we have to understand what are we trying to accomplish and provide an alternative and accessible way to do it.

in this case we are talking about a WAI-ARIA role for a slideshow, so we must provide a <noscript> tag listing the same images with accessible information; I think @felipeduardo and @polyester can give us some advice but, in the mean time, I found this: http://stackoverflow.com/q/16840054/644075

about your second concern, we are not making more requests, we are making the same number of requests but in an asynchronous way instead of sequentially. I think this must not be a problem with modern mobile browsers and modern mobile networks (4G) but that's not probably the case in our region (Latin America).

most of the issues with mobile networks seems to be related with latency and bandwidth, we need to find a way to load the images with a compromise among loading only the images viewed and loading them trying to use the keep-alive window, so we avoid having to create a new TCP connection.

here you have a couple of good readings on this:

• Does Mobile Web Performance Optimization Still Matter?
• Mobile Analysis in PageSpeed Insights

[hvelarde]

@djowett must of the stuff I mentioned above is quite trivial; I think we can implement the control panel configlet for all but the last two options (progressive image loading and swipe gestures) that I think we need to test and plan better.

I'll work on that ASAP.

[rodfersou]

@hvelarde I'm not sure if <noscript> tag is necessary in this case since we already have the html with the images into the template if we disable javascript, so we can move the inline script tag into a javascript file and don't care with <noscript> tag.

As I said before, I don't think inline script tags are evil, I just try to take then out. This is about separation of concerns, html files should be structure, javascript files should be actions, and css files should be formatting.

[fredvd]

I can't really judge on individual parameters if we are missing something there because it's depending on the cycle2 interna for which I don't know enough yet. The most basic stuff with these carousself is that if you can override the .js file where the json config for the carousel is instantiated from and/or the template where the .js file and the data elements are you're done, but this is developer customisation, not content editor.

I'm musing a bit about the 'configuration entry points ', by lack of a better translation I can come up with now. The cover usage for a caousel is that (intermediate) content editors can design a layout, drop a carousel tile there and configure it for a number of parameters. You will have to provide configuration settings for all kinds of carousel settings in the cover 'end user' interface so for cover there's less value to have an extensive global control panel for cycle2 settings as well. End users cannot get to the Plone Registry/Control Panel.

To quote the original topic "We must define a standard set of configurations " a generalisation could be to say "We must be able to define standard setS of configurations", a number of different profiles. If those can be created in the plone control panel and aptly named/labelled, the interface in add'ons for content editors could be much simpler where you would only have to provide a drop down select with the available profiles that the webmaster has created for you in the Plone Control Panel, maybe with a few really desirable reasonable overrides that even content editors are allowed to set.

But if you want to go this route it should be possible on the add'on level to select a carousel profile and still be able to override certain values, which could be tricky.

[djowett]

I think @fredvd has a point here... who's life are we trying to make easier? (if that is really his point) I'm tempted to say "just document how to override the carousel template with jbot, rather than give ourselves the trouble of maintaining:

a) this package b) more complex carousel templates in covertile.cycle2 etc"

[fredvd]

@djowett that is my point indeed, but I already jumped to a possible separation that could make sense.

Imho it's not much use to only have one big global profile in the plone control panel when it is expexted that every instance of a carousel needs extensive customisation which code/forms have to go in the add'on itself.

[rodfersou]

@hvelarde @fredvd @djowett I'm really sorry about my last message above, I missed the point in the middle of the discussion.. I was thinking about the script to init the cycle, not to configure images..

But my concern keeps as I did a test with @hvelarde yesterday simulating a GPRS connection, and the slide transition took too much time..

Maybe we will need to study if cycle2 can give us the power to make somethink like download the two first images instead of just the first one, and when change to second image it download the next too.

This way the user experience will become a little better.

[hvelarde]

@fredvd @djowett my point here is to have sane defaults for most of the features Cycle2 provides.

I understand you don't see to much value on this if you are thinking just on the tile package, but we are using it in another 2 add-ons: a photo gallery content type, and an article content type that has an slideshow view.

in our case it makes a lot of sense to have the same default values for things like transitions, speed, timeout, or even pagers and captions, as we want to give the customer a consistent UX; even the tile will benefit from this from pushing default values for its configuration.

Cycle2 also allows you to modify the look and feel of the slideshow without having to override the template (which is a developer's task), by just using CSS and the the caption and pager options (which is an editor's task).

right now I'm going to leave this here as we don't have time to start implementing this on our current project and I think we must mature the idea a little bit before pushing it.

[fredvd]

@hvelarde I do understand the need for sane defaults for other packages using cycle2, but if you can provide those as an integrator/developer in code or 2 js/template settings in the registry you're actually done per project. You don't need the extra effort of a full control panel for all the different settings for the customer to adjust (and code to transfer those fields to the template/js) if editors are not going to change them frequently.

As soon as you expose all those settings for 'end users' being site webmaster/editors in consitent & nice UX, I assume there's a frequent need to change those settings. But if that need is there it probably also means there are multiple carousels on the site with different settings <-> multiple settings defeats one settings profile in the Plone control panel, hence my plea for IF you provide an end user friendly control panel, allow for multiple settings. Because then you make it easier for the addon's like cover, photo gallery, article content types, etc. then they don't have to provide that full UI (or only for a few settings) but just a pull down for a cycle2 profile.

[djowett]

I'm still with @fredvd on not seeing the need for this.

However if you are going to have it, I would diverge from Fred's opinion on the how. I would say extending the configlet so far to have an option for each of the listed fields to say which of them can be controlled by (delegated to) content editors is a feature that is more useful (IMO) than the site-wide defaults you've already implemented.

If you wanted to go the extra mile, then provide a ready made Schema accessing those defaults & hiding fields that are not delegated (if you can do that?) - which can then be used if deemed useful in these other packages.

[fredvd]

@djowett I didn't think of and didn't intend to :-P write about setting for each field if it can be delegated (security wise) to the plugin as a setting. For me that seems to be overkill, it's probably enough to make it the add'on its responsibility to optionally provide UI to override some preset settings. My sole idea was that if you can make multiple presets (with all settings bundled under one label) for cycle2 in the plone control panel, an add'on in its most primitive version would only need to expose a select box to pick one of the presets to the end user.

[djowett]

@fredvd Sorry, my comment was confusing - I've now updated it to (hopefully) make it clear that my amendment was to the work already done by @rodfersou & @hvelarde, rather than an amendment to your suggestion.

I still think it's going to be complicated & difficult to make a solution here that meets enough needs of the depending products to provide a benefit without:

• making it more painful to maintain those products
• raising expectations of their users beyond what we can (easily) provide

[djowett]

Note on the original question: Add overlays - which (confusingly) use the "caption2" plugin. .... and possibly drop captions (generally used for "1 / 4")

[djowett]

collective.easyslideshow uses Cycle2, and has global settings and per slideshow settings too. Perhaps it is a good example of what to do here?

[hvelarde]

@djowett will take a look on it later