Composable entries is a term we use internally to describe pages that includes content composed from smaller chunks of content. Our customers call these chunks "blocks", “modules” or “sections”. This blog post explains why composable entries is a good approach to self-service page building.
Content creators want almost full control on the layout of the page. Adding content in static forms with specific fields using specific word limits that correspond to specific paragraphs in a predesigned page doesn’t work for everyone. It’s logical that some authors want more control on the narrative of the page and they can only achieve that if they have more control on a larger part of the page.
Developers, on the other hand, don’t want to give them full control of the layout as, in traditional terms, this would mean either allowing HTML input or installing some kind of WYSIWYG editor. Both are options that can go wrong in the view rendering step, as user-added-code might conflict with the application’s code.
Designers, also, need a consistent experience across all user-created pages so that this provided freedom to the authors doesn’t result in thousands of variations of the same thing. I mean just imagine how this setup might evolve if you have an editorial team of 50 authors — each creating a page a day.
This healthy tension between all three sides brought the creation of this "blocky" singular unit of page configuration which the team creates together and the editor is free to pick from a library, populate it with content, combine it with other blocks and compose their page like that — one block at the time.
As Contentful is built with structured content in mind, this setup is easily reproducible. Let’s take an example content model of a page article.
Your page will have all the typical fields, like title, featured image, category, creator but the difference is in your Body field, where, instead of having a single blob field for your page’s content you create a Reference field which can link to multiple Content types, which represent your blocks.
Here are some examples of Content types that we’ve seen in the wild:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
* Content type name: "Block: Text" * Markdown field: "Text" * Content type name: "Block: Image" * Image field: "Image: * Text field: "Image caption" * Content type name: "Block: Video" * Text field: "Video URL" * Text field: "Video caption"
By enabling the "Bulk editing" feature for the Body field you will then be able to edit all these references at once:
Then, when your author builds up a page, she can add a new entry and link it to the parent entry, reorder it, alter it and publish it.
Even though this might sound cumbersome, especially if you are "building" a simple page that only has text, images and video, things become more efficient if you try to do something more complex.
Let’s choose the example of a Slider, let’s say relevant news that you allow the user to swipe through in the form of injected cards, a usually good opportunity for advertisement:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
* Content type name: "Slider" * Text field: "Title" * Text field: "Intro" * Text field: "Call to action text" * Linked references: "Cards" * Content type name: "Slider card" * Text field: "Title" * Markdown field: "Content"
By enabling the page’s Body field to link this too, you can then start creating really rich pages that are more than just text and images. Think, sliders, fly-in information, intricately laid out image galleries and even A/B tests with your optimization service of choice.
We talked about the content editing side of things, but what about the design and coding side of your app? Starting from the design side of things, we have seen some best practices by digital teams that have applied this set up as part of their Design Ops.
Design Ops is "the practice of reducing operational inefficiencies in the design workflow through process and technological advancements" as Andy Budd of Clearleft says in his introductory article of this term. One of these technological advancements is the adoption of a pattern library, a code-focused version of a design system, which serves as a common place for developers, designers and, of course, content creators to see, discuss and shape how these building blocks look and function like.
The benefits of using a design system is that you get faster time to market by reducing friction on making design decisions or automating some of them.
What a design system might look like
For example, a non technical user might need to create a new landing page. They can now see what building blocks they can use, from the pattern library:
Then, they can combine them in various combinations to come up with the best combination, or even try out some of these and experiment:
By pairing these components to Contentful content types, the compositional interface is now in place:
There you have it, a self service page building that doesn’t drive your teammates crazy.