Content slices

Giving the power back to content editors

An article by Tom Metcalfe 03-02-2017

Over the past few years we have moved to a ‘content slice’ approach for the websites we design and build. This has been borne out of a demand from clients to have more flexibility about how they lay out their content and because of the boom in non-desktop traffic.

The term ‘slices’ is what we called them when we first started using them, but it seems other agencies have had the same idea so ‘slices’ has stuck industry-wide. 

Content slices are horizontal strips of content on a page. A little like the layers of a trifle, these slices can be layered up to create complex layouts by content editors without input from designers and developers. Content editors are given flexibility to build layers and reorder content on a page within the design constraints of the website. 

With the release of Drupal 8, the slice approach has really come into its own, offering a more flexible solution for our clients, giving them more editing control. 

What are slices for?

Slices empower editing teams to build pages and layouts in line with the look and feel of the rest of the website without the assistance of a designer or developer. Specifically, editors can build pages from slices with different content elements, columns, image placement, quotes and so on, and add slices to support a specific strategy, such as quote carousels, product highlights or calls to action. 

What do they look like?

If we take the Nesta case study page on our old website as an example, we can see a few different slice types here.  There are a selection of slices in use; the quote slice, one column text slice, full-width image slice, two column slice and carousel slice. Content editors can add as many of these slices in whichever order presents the content in the best way.

Nesta screenshot with slides labelled


On the backend the slices are provided by the Drupal Paragraphs module. Each slice on the front end is a ‘paragraph’ on the backend.

Paragraphs can be added/removed/re-ordered from the node edit page. From a content editor’s point of view adding a new ‘slice’ on our old website looks like this:

Gif to show how to select slices in the back end system

What’s great about slices?

Flexible layouts

The main advantage of slices is that content editors can create complex layouts without any technical knowledge.

When content editors just have one ‘body’ field with a WYSIWYG editor their options for layouts are extremely limited. Even splitting text into two columns would be a challenge. This is very limiting to content editors. It means that content using the same page template are going to look very similar, and content creation is restricted and dictated by the layout. With slices, content editors don’t have to worry about any of this.

With different slice options available on the same page template, a content editor has more flexibility in the layout of content, making pages look more distinct while still following an overall design. 

Takes media out of the WYSIWYG editor

The slice approach means that you can have a slice that is specifically for a type of media. This is an important one for content editors as adding media into the WYSIWYG editor can be a nightmare.

It is even more important for developers as any media added to a WYSIWYG editor is usually given a pixel width which means it will not re-size for smaller screens.

Which leads nicely onto the next reason to use slices…


Any complex layouts created in a WYSIWYG editor are very difficult to make responsive. Generally there will be a lot of fixed widths and questionable markup to create the layout.

With slices the layout styling is done through template markup and CSS which is consistent across the site. This can be styled to be responsive much easier.

In addition media in a ‘slice’ can be re-sized much easier than media in a WYSIWYG editor. In the case of images ‘image styles’ can be used to serve smaller sized images to users on smaller devices.

Encourages code re-use

As slices have consistent markup and CSS across the site, it means that more code can be re-used. Less code = easier to maintain!


This is more of a benefit for developers, but slices can be featurised via the Features module meaning slices that have been implemented on one site can be deployed to another site easily.

This also has the benefit that any changes to slices can be tracked in source control.

What’s not so great about slices?

Added complexity

Going down the slices route rather than body fields with a WYSIWYG editor means the site is a little more complex. There is a additional maintenance overhead and an experienced site builder or developer will be required to implement the slices. 


Content editors will need to be trained to use the slices approach. It’s a new approach and content editors need to be trained properly to ensure they get the most out of the slices approach. 


Services like Gather Content cannot currently push content into slices. This means any migrations will need to be performed manually. Migrating from an existing site will be made more complicated by slices and an experienced developer will be required.

All these drawbacks mean generally the slices approach is reserved for larger sites with dedicated content editors.


The feedback from clients about ‘content slices’ has been very positive. Content editors enjoy a huge amount of freedom about how they layout their content which looks amazing across a range of devices. This can be seen in action on: 

Get in touch

Contact us