High Expectations of Site Authoring and Page Layout

Plone Support Customizing Plone
21

Hey

I was asked to join the conversation by @djowett.
I'm one of the developer and release manager of ftw.simplelayout.

Here are my 5 cents, or probably 10 :grinning:

First of all ftw.simplelayout is not driven by a opensource community, but it's payed and developed by and for our customers. We try to solve their Use-cases with ftw.simplelayout.
Our customers also organise themselves in a community, so they can push somehow in the same direction.

The starting point:
Many years ago :sweat_smile: We had the following problem.

Our customers are mainly municipalities, Cities and States (Canton in Switzerland), they all faces the same problem:
They're separated in several departments and offices and it's common to have about 200 (and more) individual users, which have to manage a great amount of content. BUT it has to look the same everywhere on the site. You need to recognise the page/layout/style on every site (Usually several 10K sites)

Some example issues:

  • No images are places with tinymce, there are only 1, 2, or often 3 image sizes/dimensions allowed on the whole site.
  • Listings like galleries or files needs to look the same on whole site.
  • Startpage and Portal sites often have some different needs, like a multicolumn layout.

Our goal was to make sure:

  1. Every site needs to have the same look and feel according to the "Corporate Identity" of our customer
  2. Many users have to deal with the system and create a lot of content without any training. We usually only train Webmasters and Superusers.
  3. Manage the balancing act between flexibility to solve their Use-cases, restrictions to keep the look and feel and as easy as possible to use.

Technical solution:
History: We came up with the old BernArticle back on Plone 2.0. --> simplelayout.base --> ftw.contentpage --> ftw.simplelayout.

We are aware of Deco, plone.app.mosaic, collective.collage, etc. but as said before, the package is kind of customer driven and this does not match the goals, strategies and Use-cases of the mentioned packages.
Also the efforts we can put into the package depends on customer plans, so package may lay around for a while, without any progress and suddenly we can spent 200 hours in new features.

Of course you may point out, that if package would be community driven, there are more people involved and therefore more progress and a steady development. But I'm pretty sure the needs of the Plone community and the needs of our customers are not the same and we would end up in a tool with tons of configuration possibilities to fit all the needs everyone has.

Software desin decisions:

  • Blocks are DX-Types (Security/Workflow, Copy/Move, Folderish Blocks, API, many more. You may ask specifically and I try to answer).

  • Almost no TTW configuration. We use adapters to configure and change the behavior of Simplelayout. Only Dev's configure the sites for our customers. This is far more flexible and easier to maintain, than 100 registry entries.

  • We have Slots, Layouts and Columns (They're not DX types)

    • Slots: You can put <div tal:replace="structure simplelayout:name_of_the_slot" /> on any type, which provides the Simplelayout behavior.
    • Layouts: You can put N Layouts into a Slot. Currently a Layout has onle one property, the amount of columns it contains.
    • Columns: Contains the blocks.

  • Every page has a state, which represents the order, position, etc. of all layouts, columns and blocks.

  • The state is equal to the DOM. We convert the DOM into a JSON structure and store this in annotations on the page.

  • Blocks can have different representations (views)

  • Blocks can have more individual properties. (Like CSS Klasses, data attributes, ect.)

  • Blocks are addable/editable in Overlay

  • Never reload the page, while working on it.

  • ... You may ask for more.

Biggest issue:

Styles:
Simplelayout is heavy based on CSS. So we ended up with: "You need to install a theme to actually use simplelayout".
Why? ....aww...ehhh...
We use ftw.theming in our Themes, so you can use SCSS, predefined mixins/structures, Manage style dependencies and a lot more, like Icon libs etc. A great system. But if you only install ftw.simplelayout and ftw.theming, the Sunbirst CSS (Plone 4) makes it unusable. In all our Themes we reset everything and start from scratch. This way it's easy to put the styles needed for Simplelayout into the ftw.simplelayout package not in every Theme.
Btw: ftw.simplelayout was Plone 5 compatible, but unfortunately not anymore, we lost track of it, but it will be compatible soon.

How our customers use ftw.simplelyout

  1. Usually the know the content they need to create and arrange the layouts to their needs. This example may be a portal page.
    Screen Shot 2017-01-31 at 10.20.37.png2502×1264 94 KB
  2. Some content
    Screen Shot 2017-01-31 at 10.29.08.png2518×2096 2.37 MB
  3. Done, or the review process starts.
3 Likes
22

Thanks @maethu that's at least 20c in my book :wink:

My big question is whether you feel that using Dexterity content types for the blocks was a good decision in hindsight? (by comparison Mosaic and collective.cover use plone.app.blocks and plone.app.tiles - which means storage in "annotations").
In particular:

  1. Is performance acceptable in your opinion? Or better than acceptable?
  2. Do they interfere with other content (e.g. by appearing in search results, or stopping you easily using simplelayout on folderish content?

(other questions may follow)

23

So far yes, this allows us for example to create folderish blocks with files and images and you can still use plone default tools to move the contents of blocks and also the block itself around.
The other point is workflow: Usually blocks does not have any workflow assigned, which means they inherit the permissions from the page. But we have edge cases, where the block+children have their own worklfow. It also fits into all other tools. like addable types (FTI) or TinyMCE internal/external links to blocks.

Is performance acceptable in your opinion? Or better than acceptable?

Performance is OK, I mean it's not designed to have 1000 blocks on one simplelayout page. I did not measure the simplelayout rendering in particular. But according to a flamegraph I once made the simplelayout ITALESProviderExpression adds some amount of time. But we usually optimize other parts of the side to gain the amount of performance we need. like optimize resources, configure plone.app.caching properly. IMHO so far this is not a issue.

Do they interfere with other content (e.g. by appearing in search results, or stopping you easily using simplelayout on folderish content?

Yes they do, but the I'm only aware of two disadvantages:

  1. Blocks inflate the catalog with unnecessary data.
  2. It's not compatible with Working Copy / Versioning by default, since the Simplelayout pages are all folderish and are used to built the site tree. We have only one site running with Working copies and some custom rules/policies to make it work.

The SearchableText of blocks is indexed in the SearchableText of the Page (solved with collective.dexteritytextindexer).