Flexible Publishing Model

The theory behind the flexible publishing model starts from a recognition that technology and editorial teams often have a different understanding of "content type".

For an author or editor, content type refers to the rhetorical function a particular piece plays. A working paper, for example, is intended for other researchers, is not meant to be the author’s final considered view on a topic, is not usually peer reviewed, and doesn’t weigh heavily on tenure decisions. By contrast, a brief may be written for a high-level elected official, provide just enough argument to demonstrate its seriousness, and leave out most of the mathematics and detailed charts.

For a content strategist or a developer, content type is a technical term that refers to a specific set of content management system functionality. Roughly speaking, a content type (in this sense) is a set of attributes (or fields) that are collected into a single entity that is then published on the website.

The traditional CMS model starts from the presumption that there is a one-to-one relationship between a content type as understood by an editorial team and a content type as understood by a technology team.

Soapbox's flexible publishing model dispenses with that one-to-one relationship. Instead, it links sets of attributes (the technology understanding of content type) to templates (rather than to content types) and links an item’s rhetorical function (the editorial understanding of content type) to a set of content labels. Instead of simply selecting a content type, users will select a content template and content label. The interface resembles a user story:

I want to create a [content label] using a [template type] template.

So, for example, a user could select Blog post as the content label, then select Simple item as the template.

Content types—as understood by technologists—do still exist, but they are hidden behind the scenes. It's difficult to get around the fact that a great deal of default CMS functionality is still based on the technologist's understanding of content types.

For example, permission systems—particularly in Drupal, where most of our flexible publishing model systems are built—are tied directly to content types. So if a developer builds an event content type, then developers can use out-of-the-box functionality to build out roles like event coordinator (who can add details of the event to the CMS) and an event manager (who can review and publish those events) and can link those to the event content type. All that can be done via configuration rather than code.

Similarly, there are a number of simple Drupal integrations with schema.org that allow mapping of fields without writing bespoke code. But those integrations presume that a specific content type will match a specific schema.org type.

Our flexible publishing model will undoubtedly continue to evolve. And it's a great option for forward-thinking research organizations.

But it's also a temporary hack—one that we hope we can retire once the teams responsible for building CMSs cotton on to the fact that content type (editor) does not equal content type (developer).

make-public