The future of layout - continuing the Tokyo discussion

In Tokyo there was a meeting called to discuss layouts in the future Plone-ish world, especially in Volto and the like, initiated via email thread.

Let's move the discussion here, and I will try to capture current agreement/state of discussion in a separate document, which I will share.

Below is what I remember. I didn't take notes. Sorry its so rough and probably misses many things.

Discussion was a few fronts

  1. How much layout is enough?
  • volto is currently deliberately limited. It's focus is on a medium like, content editor focus. It only allows single column. Nothing side by side
  • mosaic was seen by many as allowing too much layout in particular how it can result ugly sites. I think gutenburg fell into "too much layout" camp too.
  • but is there a usecase for ugly sites?
    • discussion on webmaster, small organisations who can't afford expensive developers everytime they want some additional layout vs bigger organisations whose spend a lot on brand and website and want every page well designed.
  • discussion on different layout editors, including some where number of columns or sizing was a kind of tile of its own rather than like mosaic where the colunns and grids are worked out automaticly based on how you dragged around the tiles. I didn't have the example during the meeting but the one I was referring to is shown here https://rawgit.com/Kademi/keditor/master/examples/basic_with_content.html. Not very use friendly but shows the different approach than mosaic.
  • discussion went on to what would be the min amount of layout that would work for some real usecases like @polyester NGO type sites. The consensus there seemed to be the ability to have 2-4 cols but I can't remember if this is mainly for text or feature type boxes.
  1. sitelayouts/portlets/whole page layout
  • there wasn't that much discussion on it.
  • Seems no one there uses the mosaic concept of sitelayouts (for example I tend to use mosaic as a landing page system and still use portlets)
  • general agreement that still need the concept a tiles/portlets that appear on many pages

Then the openspace finished and there was another session during the sprint that was only focused on pastanaga layout and the volto implementation. This was mainly about what tiles are first to implement with a bit about layout.
@Albert did discuss his idea about how to add multiple columns in a simple way to the volto (medium like) editor. It might be better for him to keep refining it but the general idea was not to do DND with tiles but a sort of "split col" button that moves the current tile up and to the right of the one above it. I think this implied that when you had multiple tiles stacked in each column they didn't line up horizontally like a grid. Albert and I had discussions on how support a grid type layout perhaps along the lines of grouping tiles into blocks that should be kept together vertically and below that there should be a "clear" or grid horizontal alignment. No real conclusions on this though.

All of this though still leaves us in a kind of no mans land for layout. Mosaic looks unlikely to get much support. Volto is being worked on but requires a whole different way of theming that is probably going to be only suitable for expensive sites for awhile yet. Taking another supported open source layout editor and integrating it into plone didn't really get discussed much.

1 Like

Thanks Dylan!

@tisto said in another channel that he plans to write a blog post summarizing his recollection of the meeting.

Allow me to add my remarks;

  • Volto is no doubt a good solution and a great approach for a particular sort of sites but it does not solve anything or would not give us any benefits for our own typical customership
  • React & friends in the frontend is a new complexity that people have to learn if a React based frontend will the the UI future of Plone
  • for the short- and midterm future the traditional server-based rendering will be good enough for most Plone-based applications
  • an integrator or an average-skilled in-house developer should be able (as it is the case now) performing the most common customizations to templates, CSS, JS etc. without having to touch any new technology or React or whatever will be fancy at that time
  • Mosaic: we should consider this a failed experiment although it might be suitable for some corner cases. Mosaic has several issues when it comes to usability & functionality and often does not fit the requirements that we have in context of landing pages or overview pages (also "Compose" failed badly).

Conclusion (short version): Plone UI customizations must remain approachable and must not require super-skilled developers or smart frontend guys. The lifetime of a Plone portal - in particular in education - is often much longer than the normal support cycles and often see many emerging technologies coming and going. Using Plone as headless CMS is an optional approach for arbitrary frontends based on Volto or whatever. But it must always be a supplementary offers and not the default. So we must always remember where Plone came from. A server-side rendered UI must be the default and must be supported as default for the time being.

6 Likes

In all the discussions I've sat in on, the traditional Plone UI was never going to be removed; it would always be available, especially to manage the site and its content on the backend.

I disagree that Mosaic is a failed experiment. It works very nicely, especially in CastleCMS, and can certainly be used for landing pages.

1 Like

Plone Foundation Code of Conduct