Mosaic – the new layout solution for Plone

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

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.

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

2 Likes

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