Mosaic – the new layout solution for Plone

@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.

@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.

@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...

1 Like

Another teaser:

This time we are adding a new event, which has a Mosaic Layout as its default view. That's why see Mosaic's "Custom layout" already on the add form. The editor gets its default value from the configured default layout. Because the default layout already contains most of the fields, most of the even field can be filled in-line in the editor.

Also this time those fields are configured "non-removable" and "non-movable", so even the layout is "customizable", those field must remain in their places (unless user goes into browser developer tools to rewrite the HTML in the editor).

I'm surprised, how well the in-line editing already works, but the fields are still a bit hidden and tab navigation has some issues (mainly that tiles are not properly focused). Generally, I have mixed feelings about it. When it works, it's awesome, but when it's not perfect, it might be an annoyance.

I hope sprinters at Arnhem Sprint could look into it, and evaluate, if it can really be made good enough.

1 Like

@datakurre while I think deco had a vision and some documentation I think @hvelarde and Lincoln are right that we could do with more use cases than we have. What we have is an idea that may or may not work for a variety of use cases. What hasn't really been done is to collect those use cases, sort them into must have vs nice to have and then flesh our stories for each one of how you would step by step achieve using mosiac as its currently designed.
What your doing right now is exactly that, but with a working version and showing the results in videos, which is great.
Now I think we just need to go back a step and work out what all the use cases are.
So

  • multirow landing page with different styles per row. Different permissions to edit each row. (atlassian homepage)
  • user creates event with certain field locations fixed but rest flexible. default layout created by siteadmin using layout editor.
  • ??
  • ??

To me I don't see why mosiic can't be designed to do everything that c.cover tries to do.

2 Likes

Just as a note that we could already have per row permissions by using an "external content" tile per row, and maybe editing linked external content could be made easier. That would be mich simpler that implementing permission support into editor, but would result in dummy content outside landing pages.

just a quick question, @datakurre: how does indexing works in something like the teaser you just post it?

@hvelarde Mosaic, like Deco, has three different tile types: text tiles, field tiles and app tiles.

Text tiles are not really tiles in p.tiles sense, but are just HTML saved into layout field (next to other fields). Field tiles are all instances of field tile from plone.app.standardtiles. All the other tiles are app tiles.

Field tiles just show and save data into content instance fields, and are indexed by normal field indexing (if fields are configured to be indexed). App tiles are not indexed. Text tiles are indexed by indexing the layout field into SearchableText index (p.a.blocks 2.1.0 will automatically index layout field if c.dexteritytextindexer is installed and the content type has c.dexteritytextindexer behavior enabled).

1 Like

My usecase for Mosaic would be to customize it to be a Medium.com style interface.

1 Like

a picture is worth a thousand words (1):

2 Likes

@hvelarde got you. Screenshots coming up.

@hvelarde,
Here's my illustrated explanation:

3 Likes

A fun update: drafting with autosaving on both add and edit forms and also for persistent tiles.

Based on a forgotten friend called plone.app.drafts.

(Updated the example to show the possibility just add images already when on temporary add form.)

4 Likes

The next release will fix resource tiles for Plone 5 and add a toolbar tile. This bascially make custom sitelayouts usable in Plone 5.

How about a blank Plone 5 site:

2 Likes

Looking good!

Absolutely! Looking forward, using it.

Did a short demo this week at the Zurich Plone Meetup and fellow Plonistas were quite impressed!
What we really have to figure out, is what functionality should be exposed for which usecase and where - ui-wise.

That said, thanks again and looking forward to the Anniversary-Sprint!

@agitator That's great news. Please, discuss about those during Arnhem sprint. But whatever you decide, please, try to find a minimal route for production.

Mosaic is already technically good enough for me, but I'd prefer to make it suite also for others at the community (and maybe later included into core distribution) to share the maintenance effort. If we manage to "break it" because of too ambitious incomplete refactoring (this was the issue, which prevented Deco from ever getting ready), I may have to fork the last working version for myself, and that would be a pity.

1 Like

@datakurre great job, I think I'm going to roll this into production ASAP.
I have been waiting for almost 6 years (http://www.slideshare.net/robgietema/deco-ui-european-plone-symposium-2009)

@rnunez Cool. If it's up to me, there should be upgrade steps for new releases. Also, follow open bugs in https://github.com/plone/plone.app.mosaic/milestones/1.0.0

Plone Foundation Code of Conduct