Mosaic – the new layout solution for Plone

[datakurre]

It's time for a new thread for Plone Mosaic.

Mosaic is the new layout solution for Plone. It's based on the technologies built for Deco, but unlike Deco, it works nicely together with your existing content types and views. Also, it doesn't need to be complete to be usable, but it's possible to polish it into a minimum production quality product, and continue from there.

Deco was revolutionary UX in 2009, and it's shame that Plone could be the last CMS getting it.

Mosaic targets Plone 5.1, but is still [2015-04-28] compatible with Plone 4.3.

There's up-to-date introduction with screenshots for Plone 4.3.

And more information is available at GitHub.

The first minimal release for Mosaic would simply provide Layout behavior for Dexterity content types. A content type with layout behavior has a new (optional) default view called Custom layout, which would display the new tile based layout for the content. The first release would ship with only a minimum set of default tiles for the layout, but the framework is already extensible with your custom tiles.

Give Mosaic a try to see, if it's close enough for you and whether you could contribute to make the first production quality release. You can deploy the current development preview for Plone 5 to Heroku with just a few clicks.

Note: Currently, too many of the available tiles (besides "text" tile and "field" tiles) are broken in one way or another, and fixing those (technically plone.app.standardtiles) is the main work left to do.

Later Mosaic could slowly provide all the features promised for Deco (technically most of those are already included in the backend, but require significant effort to be easily usable from the front end).

[gforcada]

I can hardly thank you enough for all your work on Mosaic, and as you painfully remember, since 2009 we have this baby around without caring to finish it!

As a pre-oficial announcement, we are planning to host a sprint about Mosaic in September in Berlin, so keep looking at flights if anyone feels like making a major difference in Plone for the coming years, Mosaic will be it!!

[agitator]

Also a BIG thank you!
Planning to help on Mosaic at the fourdigits Anniversary Sprint.

[thet]

@datakurre can mosaic also replace the portlet machinery? including the features, we already have - persistant configuration, predefined slots, inherited portlets and so on. or should it coexist with it?

[gforcada]

Maybe I got it completely wrong, as soon as you have site layouts you can just use them for sharing the "portlets" between different pages, content types and so on.

Actually the cool thing here is that as you will be able to create and change the layouts TTW you can mix and match as much as you like: complete freedom!

[datakurre]

@thet Eventually yes. Once we are good enough to reveal site-layouts, Mosaic could replace both viewlets and portlets. And in the best case, the composition can be done by Varnish with ESI or by browser with AJAX so that Plone's traditionally heavy and slow requests can be splitted into multiple small (and individually cached) small and fast requests.

That said, the Mosaic composition is so much simpler from the portlet engine that we are still missing TTW configurable permissions (think about group portlets) and cumulative inheritance of portlets (context portlets adding more portlets in each hierarchly level). I'm sure that these can be done, but the most performant way still needs thinking.

To rehearse the Mosaic composition (plone.app.blocks' transform chain):

• For each content instance, a content layout is retrieved.
• Each content layout contains URI of its site-layout, which is retrieved.
• Site-layout (think about main_template, which we also use as a fallback until we are ready to use tile-base site layouts) can define any amount named "panels" (think about metal:slots), which are filled from matching panels from the content layout (or left with their default content).
• Once matching panels have been filled, all tiles are resolved and the result is rendered as the response.

The first version of Mosaic will hide the site-layout feature so that the legacy main_template with only one content area panel is used.

Otherwise the current implementation allow to override the site-layout per section (folder hierarchy) or per instance (think about folder default pages).

Eventually, we may need something more flexible, but we have to start from something.

[datakurre]

An update with a teaser:

Mosaic is getting ready for those promised sprints. All tiles, but "Media tiles", should now work. There's also support for custom styles (via registry configuration) per tile and per tile row. It should work well enough to give a attractive demo and motivate others to get it finished and released.

That said, field tile behavior may depend on added field type, and not all available portlets may make sense as tiles (also portlet tile may have hidden issues, why we may not want to enable it by default). Testing needs a lot of work. Blocks composition is quite well tested, tiles base framework is somewhat tested, but Mosaic has only a few very basic acceptance tests. (Mosaic Editor has outdated unit tests, but they are not run at CI, so they basically don't exist.)

Issue list for the first milestone should give an overview, what's supposed to be left.

[pigeonflight]

@datakurre... There's only one way to say it that captures my feeling about your work on Mosaic... "Big up and Respect!".

[datakurre]

@pigeonflight @gforcada @agitator Thanks for the kind words

Yet, it's good to remember that Mosaic stands on the shoulder of giants (or on the ruins of Deco). Those new to Deco, might be interested in reading the original proposal (from 2008!), which was retrieved during the last Plone conference. Many technical details have changed since that, but the main concepts and most of the original code base are still around in Mosaic.

[hvelarde]

@datakurre you deserve your own place in the Plone Pantheon indeed

now I just want to add a couple of things: we want to start removing from collective.cover all the stuff we can and we want to help you guys in some way as we have a lot of experience on layout and tiles stuff.

we want to use (when viable) plone.app.mosaic as our layout editor and we want to implement compatibility with Plone standard tiles by finding a way to configure them à la cover. collective.cover work needs to focus on it own stuff and not on layout editing or tile creation/maintenance.

this will take some time because we have very limited resources and some big projects that depend on our product (two distributions used by the Brazilian government, among them).

now, one last word: I was looking at the issue tracker in plone.app.mosaic and I found a lot of familiar stuff there; I want to repeat now something I said almost 3 years ago: please learn now from our own mistakes, don't repeat them.

for instance, have you think about having groups of tiles in a row (columns)? have you think about responsiveness an different grid systems? what about permissions? do we really need a portlet tile? no, really? the image tile, the embed tile: the code is there… be careful about persistence… be even more careful about annotations… review… ask… think about it and lead us to a better place.

[datakurre]

@hvelarde Well, still a lot of work to replace c.cover (and I haven't seen much resources for Mosaic either):

• plone.app.blocks 2.0 has support for transforming certain syntax into any grid system, but that's not yet integrated into Mosaic Editor in p.a.mosaic
• I'd prefer all transient tiles; our "text tile" is just HTML in layout field and most of p.a.standardtiles have already been refactored to transient, but images, of course, need some solution; Ramon and Nathan had some idea for generic approach (plone.app.mediarepository replacement) for uploading images / attachment; alternatives are integrating / fixing / finishing plone.app.drafts or plone.app.mediarepository
• I share your concerns against portlet tile; it feels dangerous and I'd prefer to disable by default
• no predefined fixed columns like in c.cover; I'm hoping that we can solve those issues with "site layouts" and some kind of templates (because it should be trivial to copy & paste set of transient tiles)
• no fine grained permissions; Mosaic Editor supports non-removable, non-movable and non-editable tiles in templates, but at the end everything is stored in single layout field protected by cmf.ModifyPorrtalContent; Mosaic can support easily only two roles: one that can edit everything and the other that can edit only editable areas

[datakurre]

@hvelarde The most important current "resources" for Mosaic is some sprinting at Arnhem Anniversary Sprint at June (at least @agitator is sprinting Mosaic, but also Rob is probably available there to help if needed) and Berlin sprint at September by @gforcada.

[djay]

@hvelarde I think what mosaic lacks is the kind of motivating story like you had with cover news editors and sports sections. Obviously mosaics is trying to do "more" but its not yet clear how much more. What we need is concrete layouts and the stories behind how they will get created and edited to really nail down what mosaic should and shouldn't do.
For example should mosaic be able to create a frontpage like this? https://www.atlassian.com/
Or is this c.cover not mosaic?
How much diazo should be used in conjunction?
Is this only the kind of layout that can be created outside the layout editor using site layouts?
How much control could we give to editors within a particular panel? or tile? How much restrictions?
What happens if we want to translate the content on that page but keep the layout the same and the content is not in fields?

[djay]

@datakurre one thing I'm saying here is we need to drag this out of technical details like transient tiles and start talking from a user perspective to ensure what is being built is actually useful.

[agitator]

@djay yes, frontpages like atlassian should be possible with it
and yes, we need some ux/user stories

[datakurre]

Personally, I've been mostly working for the Mosaic backend to make is possible to define content type views TTW (not depending on theming). There everything but i18n for view names and nice UI for copying layout into named content type view is ready. Because Mosaic Editor is technically just a z3c.form field and a widget, it should be possible to make it part of Dexterity content type editing experience.

Then there are site layouts for customizing sub site layouts different from the main site. This like everything nowadays seems to be balancing between content instance configuration and theme.

[hvelarde]

@datakurre I think the whole idea of p.a.mosaic is to replace Deco and not c.cover.

Deco was the layout composition system proposed for Plone; c.cover is a composite page content type that has an embedded layout editor and some predefined tiles, just because there were none of those when we started working on it.

I think @djay is totally right when he says that p.a.mosaic lacks the use cases of c.cover and you have to be very careful in this stage of the development. and I think that's why Deco never took off: the demo just looked like anybody would be able of messing around the structure of a content type instance, breaking the structure of the site and creating a CMS nightmare.

don't make the mistake of trying to turn p.a.mosaic into c.cover "lite", @agitator.

keep p.a.mosaic clean and simple, doing the one thing the it's supposed to do: which is... _____?

time for my Abraham Lincoln's favourite quote: Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

[agitator]

@hvelarde i know for your usecase, the separation of "compose" and "layoutedit" make sense, for others it's a real pain. I don't want/need a fixed layout that i can fill. I would like to have a flexible solution to finally get rid of just the text field and be able to build more complex pages, instance by instance.
And imho nothing speaks against building pages like the atlassian example with mosaic.

[hvelarde]

@agitator the separation of "compose" and "layout" doesn't make sense for anybody; is just the way the package was born and we had a lot things to fix before that. as I mentioned: I don't want to have to maintain the layout editor at all.

one the other side, I don't want to discourage you; you can do whatever you want; I'm just giving my opinion based on my experiences.

I can do the Atlassian home page right now with c.cover; I can even use something like collective.advancedpage if I don't want to use c.cover.

why should I wait for p.a.mosaic then?

we need to focus on what we want p.a.mosaic to do and it has to do it right.

[datakurre]

@hvelarde @agitator I don't think it hurts Mosaic that Peter would work with Ramon to add the missing features (like transient media repository based image tiles and most important missing TinyMCE actions like linking) to layout editor to make it work for nice front page layout.

I'm also pleased to know that nobody expects Mosaic to replace c.cover, and it's OK that they remain separate. Yet, it's good to know that the current layout editor has API for registering new actions, and it should be remain like that so that other add-ons like c.cover could later add domain features they need.

Remember that Deco (which Mosaic aims to finish) was one of the three Ds, from the era where Plone still had spiritual leaders with somewhat clear vision about the future. Dexterity for content types (schemas), Deco for content layouts (views) and Diazo for theme adaptation. But because Deco never came, we started to replace it with Diazo, and that's why I feel like continuously stepping over toes of Diazo with Mosaic...