How to implement carousels, tabs, accordions?

[datakurre]

Currently, the only way to add carousels, tabs, accordions etc... into a Mosaic page is by custom tiles. Yet, that would be counter productive, because mostly likes to just wrap existing tile types into those.

Not sure how this should be achieved.

Probably the editor could support adding some patterns via its row / tile format menu. For example, a carousel pattern on a column of tiles would probably make the column work as a carousel.

But how to both make the pattern WYSIWYG and prevent it from breaking the editing experience? Probably not trivial.

Another issue would be that columns are dynamically created and destroyed when tiles are added, moved, removed or columns are scaled.

Yet, whatever happens, I'd like to keep the current implicit grid management (even it causes losing column specific pattern configuration every now and then; restoring them should be easy enough).

@vangheem Did you though about these, while trying out Mosaic and working on the editor?

[djay]

The way I would probably create a carousel is similar to how we do it now

1. Create a custom style for a tile
2. create diazo that looks for the custom style and a list inside that tile. Turns that into a carousel
3. apply to a tile.

But an improvement would be a schema driven tile creator, where you

1. create a new tile type
2. set it to a schema with list of (richtext field, title field, image field).
3. create diazo rules to turn the auto generated html of that tile into a carousel
4. add new tile.

Neither are WYSIWYG but I really think that is unrealistic. I honestly think the only real WYSIWYG approach we can home for is a side by side editor like craft has.

[gforcada]

Is there any concept of tile containers? Because then, one could create a tile container, put tile images on it, and apply a data-attribute on the container to specify its behavior (tabs, accordion...). This could play nicely with mockup I guess.

[datakurre]

@djay I agree that just being able to tag tiles with class names (possible, but requires easier way to configure [also in theme, as discussed before]) would make it possible to do anything with diazo and custom js.

@gforcada That's something I'm thinking. There are no explicit containers and I'd like to avoid them to keep the editor simple. Yet, the editor wraps tiles into grid, which makes vertical list of tiles to be wrapped into a grid cell. That could be used as a container for pattern. (We'll also need more control for grid cells later to support viewport size specific tiles supported by e.g. BS3. grid) Maybe grid cell could be annotated with a pattern configuration and then existence of that configuration visualized somehow in the editor.

Two known issues with re-using the implicit grid for patterns:

• Cells are removed and created in fly while reorganizing tiles. This would make it very easy to lose the pattern by accident, yet if it is easy enough to apply it again, this won't be an issue.
• Rows cannot be forced. If the whole page has same amount of columns, you'll only have a single row. Probably we need a way to force row splits, but this may require overhaul for the layout editor code and a UX innovation to split and join rows.

[hvelarde]

@datakurre in our experience it is a bad idea to have to maintain a carousel tile: they are complex and difficult to configure and besides everybody has his own idea of what library you should use; in collective.cover I want to get rid of such tile (https://github.com/collective/collective.cover/issues/485).

@ebrehault wrote an implementation that uses Bootstrap and I think that's the only thing that will remain on the code (https://github.com/collective/collective.cover/pull/470).

[datakurre]

@hvelarde I agree that a specific tile would be a bad idea. Instead, I'm thinking about a generic support / convention for applying some custom behavior (be it carousel, tabbing, accordiong, ... ), possibly with pattern, for a group of tiles.

[vangheem]

@hvelarde right! carousels seem so dependent on themes that generic ones are generally not very useful in practice.

That being said, is there a way for themes to provide tiles?

FWIW, I have created carousel/gallery tiles. I don't think the configuration is that difficult to get right.

[hvelarde]

@vangheem it depends on the library chosen; we made a bad decision with Galleria: it appeared fine at the beginning, but theming was a nightmare.

[vangheem]

Yup.

[datakurre]

@vangheem collective.themefragments adds "Theme fragment"-tile, which is configured to show fragment configured as tile from theme.

1. Install themeframent add-on
2. create fragments -folder into theme
3. add tiles as page templates

4. configure titles for tiles in manifest.cfg:

    [theme:themefragments:tiles]
    basefilename = Title

It also has support for supermodel XML based configuration (foo.xml per foo.pt), but that's even worse documented :) (Static layout [tile data override] support is still WIP in c.themefragments master and is neither tested or released.)

Yes, we'd need some interface for dynamic tile providers for Mosaic so that e.g. c.themefragments could provide tiles directly into insert menu.

[djay]

@vangheem totally agree carousels are a theme thing. Everytime we start using plugins with lots of js we end up with theme issues at some stage. Perhaps facetednavigation is the only exception we still use and even that is a bit of a pain. Would love to see most of that replaced by the right combination of mosaics and tiles.

@datakurre I think if you want a way to signal that several tiles should be combined by the theme you don't need the concept of a group. You could have a "carouselpage" style which you apply to each tile, then some diazo that grabs all those tiles in a row and combines them. Still kind of ugly because what if you have 10 pages to your carousel? Kind of messes up the WYSIWYG nature of mosaic. Best way is likely the super model approach where you can specify a list of richtext fields. Does the schema editor let you define files which is a lists or dictionaries of fields?

[datakurre]

Thanks for the input. So, to summarize:

• carousels, tabs, accordions, etc... are usually so tied to theme that common solution may not be worth of the effort
• it's no issue to do a site specific tile or do those in diazo

So, instead of looking into "tile groups and native pattern support", the effort should be put to a better theming integration:

• a built-in theming plugin to configure row- and tile-styles (the format menu) from theme (rich text styles are already included by re-using the Plone configuration)
• tile- and row-classes added by format menu should be made more visible (e.g. make them visible on mouse over) to make it possible to see which tiles are "tagged"
• it should be possible to provide first class tiles in theme (e.g. instead of "theme fragment tile" on should be able to see directly the available tiles)
• schemaeditor support for theme-editor to make it possible to build configuration for theme provided tiles

[djay]

+1. All those ideas sound awesome.

Also

• ability for schema driven theme tiles to not have to create a ZPT (ie automated html which can be diazoed).
• a more configurable listingtile similar to c.listingviews would also make certain use cases easier.

For example,

• you put a bunch of pages in a special folder.
• you create a listing view specifies query for that folder + selects just the fields you want to show in your carousel e.g. title, body, leadimage
• you add your tile and get your generic listing (using LI).
• you add a custom tag “listing2carousel”
• configure diazo to take the listing and turn it into your theme carousel.

What would be even nicer is if that listingtile configuration could somehow be saved in the theme as a special tile? So we could save in the theme, not just schema tiles, but preprepared tile instances? This means you can create plugins for very generic type tiles and let themers customise them to make them theme specific.

[datakurre]

About listingtile. The current folder listing tile in p.a.stdtiles has only few fixed templates. Fixing that with listingview like view builder might be nice if it could be made easy to use with nice defaults.

About tile defaults. The current tile configuration schema already has field for default value, but that's only used for text tiles. Maybe that could be used to save a transient data query string, which the editor would use for app tiles. Querystrings are ugly, but flexible for supporting unexpected schemas.

Dylan Jay kirjoitti to syyskuuta 24 10:33:38 2015 GMT+0300:

+1. All those ideas sound awesome.

Also

• ability for schema driven theme tiles to not have to create a ZPT (ie automated html which can be diazoed).
• a more configurable listingtile similar to c.listingviews would also make certain use cases easier.

For example,

• you put a bunch of pages in a special folder.
• you create a listing view specifies query for that folder + selects just the fields you want to show in your carousel e.g. title, body, leadimage
• you add your tile and get your generic listing (using LI).
• you add a custom tag “listing2carousel”
• configure diazo to take the listing and turn it into your theme carousel.

What would be even nicer is if that listingtile configuration could somehow be saved in the theme as a special tile? So we could save in the theme, not just schema tiles, but preprepared tile instances? This means you can create plugins for very generic type tiles and let themers customise them to make them theme specific.

---

Reply to this email directly or view it on GitHub: https://github.com/plone/plone.app.mosaic/issues/139#issuecomment-14283914

[djay]

@datakurre I find carousels based on listing folder contents not that useful. Generally we do them by using richtext and using diazo to convert a

. I'm wondering if the inline tile concept might be useful though. You could then have a tab tile that could be dragged inside a richtext tile. or a carousel pane. Then diazo would combine them on render. wouldn't be wysiwyg though. ... unless rich text tiles had a render mode and edit mode where the html was different, ie diazo was applied to the rendered mode.