Change layout without destroying layout settings

[davidjb]

Are there plans for allowing changes to layouts without destroying the customised settings / tiles etc associated with the current layout?

I'm currently testing plone.app.mosaic for use and looking at how switching a content item to a new layout functions. As it currently stands, it appears that any custom tiles (eg text, images, attachments etc) will be lost and thus need to be created/reuploaded from scratch in the new layout. On a highly-customised page, this would be difficult and time consuming.

To avoid this, a solution could be (assuming technically feasible) to place all tiles from the current layout at the end of the newly-selected layout, meaning nothing is lost. There might be duplication (such as Field tiles), but it would be easy for the user to delete the duplicates, and then drag-and-drop existing custom tiles into new positions. This would be easier and less destructive than having to recreate the layout and tiles or copy-paste content.

Tested with latest master of plone.app.mosaic and Plone 5.0.4.

[datakurre]

@davidjb Thanks. This is a bit more involved, because we want to support both 1) shared layout 2) customized layouts. With "shared layout" it's not possible to append new tiles into layout. And currently changing the layout always returns to "shared layout" mode. Maybe your proposal would work, when we would assume that when a layout is customized, changing layout should automatically be customized as well (and then something else should be provided to return to "shared static layout" mode).

With only "shared layouts" (without layout customization) it's already possible to "move" settings between layouts by configure matching names/ids for tiles in layout editor (by default the editor creates unique UUID based names/ids for tiles).

[vangheem]

It seems to me like the "change layout" button should have the option to "Merge existing tiles" or something similar and drop user into customized mode when chosen.

[datakurre]

@vangheem Sounds good. Should be its own action between change and save?

[vangheem]

Maybe it should be an option on the change modal when you are selecting the layout?

[datakurre]

Then it should probably be selected by default when layout has been customized.

[datakurre]

Unfortunately, I've not been able to work much on Mosaic lately. When I do next time, I give one more change for "site layouts".

This issue was not this big issue in the original Deco design, because site layouts were the only "shared layouts" and changing site layout did not remove tiles – only moved them around with re-positioned panels. Of course, the current shared "content layout"-model gives more control, but I'm interested to see, if site layouts could work well enough – especially with the current layout menu for content layout presets.

I believe that the greatest failure in the earlier site layout experiments was splitting the site layout into too small (practically) mandatory tiles (still available in plone.app.standardtiles). It resulted in very verbose site layouts and the original idea of each site layout defining the complete layout started looking too much work. Also, I can now assume that portlets and viewlets are not not going away any time soon.

So, what I will try to experiment, is probably be something like:

• re-define minimal default site layout (with minimal amount of "boiler plate") for Plone 5
• add all the content layout manifest enhancements (icons, type restrictions, etc) also to site layouts (if some is still missing)
• "layout => change layout" would mean changing site layout (and would never lose tiles; if the new layout would not include all the panels in the previous layout, moving orphaned tiles to the last panel would be trivial)
• "layout => change preset" would mean the current layout change
• global setting whether "customize" layout should be the default when changing "preset" (current "layout")
• "layout => save" would become "layout => save preset".
• new "site layouts" could only be defined in the portal settings, but they would require significantly simpler markup than now

I could probably do this in a such optional way that it would not break anything in currently supported use cases and would actually benefit from all the work for the current "shared layout" approach. Having users to customize layout by default would be easier now that there's easy way to restore a working preset.

[davidjb]

Thanks @datakurre, this is making more sense now -- I've also had a re-read of the Mosaic documentation. My thinking was to ensure no data would be lost in a layout change (whichever type it is) so what you've proposed in the latest comment makes sense.

Fwiw, for me, as someone just picking this up as a developer-come-user, the terminology is a touch confusing; #125 helps but it might be worth giving thought to what makes sense to users/admins. Perhaps '(preset) content layout' vs 'site design' might work -- mainly a distinction between what affects the content and what affects the overall site.

[datakurre]

@davidjb Probably we need both approaches in this issue. Mosaic without alternative site layouts / site designs is simpler to understand, but makes these kind of issues, because it was not the original design. Yet, this currently enabled simple model has been well received and therefore requires "Merge existing tiles"-feature when changing content layouts / presets.

Now that you have studied the current terminology, how about

• layout (menu) => design
• site layout(s) => site design(s)
• (content) layout(s) => content preset(s)
• merge current tiles => keep custom content [requires same permission with customize-button and is default when content has been customized]

Dropping "layout" term might be good. It has been confusing. I also like "design", because site layouts are easily very dependent on theme. Also this would avoid conflicts with the current UI.

[datakurre]

@vangheem Both of these options would also solve the issue we had with orphaned tile data annotations in ZODB. Once it's possible to keep old tiles while changing layout, we can always clear the rest (drafting in p.a.tiles is probably still the place; and luckily all tila data annotations have tile-prefix).

[vangheem]

@datakurre Maybe we need to have a meeting about this.

Right now, I have Plone configured to not use any portlets or viewlets and all "site layouts" are just html files in the currently enabled theme using plone.app.standardtiles in the layout.

The real problem I see with "site layouts" and "content layouts" is the confusion that happens when you bring in theming. My approach solves the theming issue and simplifies the original diazo design.

I don't agree with the full-blown deco design--I think it's too complex for most to understand and manage.

Again, I think we need to spend sprint time understanding everyone's ideas and approaches and sketching out solutions long term--let's plan on taking some time in Barcelona to do this.

[datakurre]

@vangheem Agreed. Let's spend time with this at Barcelona. It's even quite related.

I'd like to hear more about your configuration. I agree with site layouts overlapping with theming. With filesystem resource directory there's less confusion, because different resource directory types are next to each other (now it seems, we are slowly adding everything into theme-resources, because of theme editor).

Confusion between site layouts and content layouts was probably a mistake at the previous Barcelona sprint. Originally there was no term "content layout", but just content.

[datakurre]

@vangheem "Site layouts" vocabulary could be built from theme as well. E.g. from ./layouts directory from current theme, saving not-completely-theme-bound @@theme-layout/foobar.html into sitelayout fields in content. That would be somewhat similar to how collective.themefragments work.

[davidjb]

@datakurre, about the terminology, I ran this by a couple of colleagues (end users of Plone and other CMSes) and the feedback was that:

• layout (menu) => design -- much clearer
• site layout(s) => site design(s) -- much clearer
• (content) layout(s) => content preset(s) -- suggestion was that content preset on its own implies pre-defined content properties (eg title, description, body) rather than relating to how content is displayed. No clear suggestions on this one that would distinguish from site design, but suggestions included "content layout(s)", "content preset layout(s)", "content design(s)", "content structure" and "default layout(s)".
• merge current tiles => keep custom content -- suggestion was the term content could be ambiguous with content layout/preset; perhaps 'keep custom tiles'

In short, the term 'design' seems to be most descriptive, and but there's confusion over what pertains to overall site design and the layout of the content area.

[datakurre]

@davidjb Thanks a lot. Terminology is hard and feedback like this is invaluable.

If either of "content layouts" / "content presets" feel ambiguous, that's because they are. If you have very structured content type with a lot of custom fields, very little is inline-editable in Mosaic and content area in Mosaic Editor is mostly about layout. But it can also be the other way around so that only dublin core metadata (including title and description) is stored in fields and all of the main content is in "content layout" (which actually stored as a property named "content"; and I'm beginning to regret that we started calling it "content layout").

If "content layout change" would set default values for visible empty fields (title, description, body, ...), maybe "content presets" / "keep custom content" would the be closer to truth than "layouts".

I'll make a branch for this, so that we can discuss about this with Barcelona Sprint sprinters in May.