Fred van Dijk: Volto Information Architecture

Link to talk information on Plone conference website.

I am using Plone since 2002, but am not a frontend expert. So currently I still have a bit of an outsider view on Volto, but I am working at Kitconcept now so will gain more experience.

Central thesis in this talk:

We need to rethink and upgrade or extend our content types and blocks system for Plone 7 and beyond.

For a big project at Zest we needed to migrate a website from Plone 4 to Plone 6 with Volto. I and colleague Maurits are mediocre frontenders at best, so we had help from two frontenders, though they had no experience with Plone or Volto.

We have almost all the building blocks already: distributions, the most secure CMS, the composite page editor, dexterity behaviours.

To do: generalised and connected frontend-backend configurations, devcontainers, version 3 of the block model, more documentation.

The big project: upgrade of the main website of the Flemish environmental agency, kind of the little sister of the European environmental agency. A communication agency came up with 20+ content types and a functionality geared towards Drupal. But the existing site was Plone 4. There were far too many inconsistencies in their design. Let's just start.

Old site is still online: https://www.vmm.be. The new site will go live tomorrow: https://vmm.vlaanderen.be. Not the greatest timing, but at least I have no talks tomorrow.

Versions used in this project: Plone 6.0 backend, Volto 18 alphas at first, now 18.1.1, Volto Light Theme. Still a Cookiecutter template as basis, if we would start now we would use Cookieplone.

Main assumptions in the Volto information architecture:

• Composite pages are now built-in, with blocks layout almost everywhere.
• Pages are folders.

Challenge: Where do you store images that belong to a page? If you are still adding the page, there is no place yet for storing the image. Store it in the block? No: use references. Put the images in a folder and reference it from a page.

Metadata images: we have lead images for listings and header images for the top of a page. The design should limit the aspect ratios and sizes, preferably just two are three sizes. That is more pleasing to the eyes than 10+ differently sized images on a page.

Media and data (for example graphs) belong in data content types, and their presentation should be in blocks.

One block to rule them all: we have the teaser block in core Volto now. Then we define adaptations/variations for presenting the different content types.

With Volto the editors can go wild on landing pages. Danger: they also do that in detail pages, which may not be what you want. Templates to the rescue: you can create an initialBlocks configuration. We added metadata (subtypes) with which an editor could say what kind of page it is.

"Listy" blocks: you can either use a grid block with teasers, or a listing/search block. They can look the same. But the design had lots of combinations that should be supported, and then all kinds of exceptions came up. To the rescue: default variants. The default teaser block variant can adapt itself to the listing.

Responsiveness: we sometimes have 2 blocks in a listing or grid, sometimes 3 or 4, needed to deal with that. Needed to fix some restrictions with the search facets too, needing to be able to choose different vocabularies.

We have three layers: the visual side of Volto, then information architecture concepts, then the backend. Idea: connect frontend blocks with backend instance behaviours. Then you have no explosion on content types.