Don’t reinvent the block

A commercially supported SilverStripe module for content blocks is on its way!

SilverStripe is rolling out a standardised and commercially supported content block module across the Common Web Platform (CWP), SilverStripe's Platform as a Service offering for New Zealand government websites. We’re bringing together the most functional and effective elements of content block modules that have been developed by the SilverStripe community. 

Our goal is for this module to become the preferred approach for managing content within CWP and the wider open source community. The module will create more flexible content structures, allow for more control over page layouts, create consistency for developers and content authors working across different sites, and focus the combined efforts of community contributions.

So many blocks, so little time

Over the years, developers have made huge investments enhancing Silverstripe CMS so that the content of web pages can be customised more easily. This functionality is built on top of the regular installation of SilverStripe and, at times, made into modules that can be reused across different sites—we call these content blocks.

However, the term ‘content blocks’ means different things to different people. What we’re referring to is the ability to break up a web page into smaller modular parts (or ‘blocks’) that allow content like banners, text and media to be independently managed within the CMS. Typically, content blocks can be arranged based on design requirements, increasing your layout options.

Currently, there’s a wide range of these content block modules with varied functionality and user experience. While this allows tailored designs for individual sites, it creates frustration and inefficiencies for those trying to maintain and manage content blocks across multiple sites. It also results in duplicated efforts across the open source community.

Taking out the guess work

Hoping to find a solution to these issues, we conducted user research that generated valuable insights into the needs of government users of SilverStripe CMS.

We set out to validate whether creating a standardised and supported content block module would benefit the majority of CWP users. We interviewed and observed users in more than a dozen digital teams using ‘blocks’. The teams varied in size and used existing modules or bespoke content block customisations in their CMS.

As part of the research, we tested a set of assumptions about how content blocks are used.

• As content blocks have become popular, a variety of open source modules have led to an inconsistent user experience across different CWP sites.
• CWP agencies can not easily take advantage of the flexibility of content blocks without a supported module option, increasing the amount of site-specific support they must invest in.
• Current modules don’t provide full version history, for example to comply with archiving standards for the Public Records Act 2005 in New Zealand.
• Content within content blocks is not searchable within the CMS or websites they’re used on, leading to difficulty using the search functionality within the CMS or on the website itself.
• Supported SilverStripe modules are often not compatible with the content block modules developed by the community.

Through the research, we found these assumptions to be true for the majority of users with the issues more prevalent in some agencies than others. Sometimes this was because sites didn’t have the latest version of their chosen module, bespoke development didn’t include the right features, or functionality had been stripped out to avoid ongoing maintenance.

Even when different sites use the same content block module, the user experience still varied because of version differences, interface language modifications and bespoke additions.

Other areas that we identified could be improved included preview functionality and content workflows. Content blocks had limited preview abilities, which made it hard to find the right block to edit, and few content block modules had workflow features making it hard to track work in progress versus work for review or publishing.

We also observed that content block modules were popular with both developers and content authors. Page templates without content blocks were rarely used if a content block module was available.

When it came to functionality, participants generally wanted the same basic features. For example, users preferred to publish at a page level rather than at content block level (although there were sites that needed publishing at a block level so that blocks could be managed by different people or remain in draft while others get published). Similarly, users found managing blocks outside of a page context overwhelming, as they found it difficult to locate certain blocks when given a large central list of all blocks for the site.

Where they differed, was in the type of content blocks they required (for example, banners, tables, or documents) for a particular site.

A major finding was that government agencies aren't too dissimilar from private sector sites in their structures and need for customisation. You might think that public sector sites are behind the times, but this isn’t something we observed. It seems government agency sites are hot on the tail of the latest web trends and focused on delivering accessible and easy to digest content.

Building on Elemental

After reviewing community modules, we’ve decided to make the most of an existing content block module, called Elemental, owned by DNA. This has been the hard work of John Milmine and the DNA team. We’ll be coordinating our development efforts with them in the future. Elemental delivers much of the functionality we observed as fundamental to content block modules and includes many of the features available in other modules.

Where to from here?

We’re really looking forward to launching this feature, but we have some more work to do yet. Next we’ll be focused on:

• Getting Elemental supported with the current user experience
• Prioritising the most important blocks for an MVP to ensure there’s enough examples to get people started
• Aligning the module more with the New Zealand government's Web Accessibility Guidelines
• Ensuring all content can be versioned and that there is an appropriate interface to manage versions
• Incrementally improving the user experience and interface through prototype UI testing, likely so that it doesn’t rely on a typical gridfield appearance

We’ve definitely got our work cut out for us—this is a substantial piece of work and will radically change the way SilverStripe CMS is used. The initial phase is being supported by CWP co-funded development hours and will keep us busy for the coming months. Beyond that, there are further plans like extending the MVP block set, ensuring there are suitable guides and documentation, adding activity feeds, and migrations from existing modules… but let's leave that for a future post :).

You can expect the upgraded and supported module to be available by December for those using SilverStripe 4, but if you want to stay up to date join us on the SilverStripe User Slack channel for content blocks.

 If you're interested in being part of future research, either as a developer or a CMS user, you can sign up to the SilverStripe User Research Panel.