A Content Hub for better content at EMBL

Even organisations of modest size have web presences where content is hard to reuse and compromised editorial experiences. Even a robust CMS and internal development team is not enough.

I have often encountered:

• “We use WordPress and that’s been great for our main website, but we also want to use our staff profiles on our Joomla client support site.”
• “Hey Tim, I put the news article up, can you copy it onto the blog?”
• “I hate writing and proofreading in the Drupal site.”
• “There’s a page on the website I think is out of date, but I don’t know who originally supplied the content. Any idea who I should contact?”

How EMBL is solving it

Organisations create many types of content, and the content hub concept enables high-quality content creation by allowing multiple editing tools and enables use of the right content in the right place thanks to curation with meaningful metadata. The content hub is part of wider effort to use metadata to connect goals to content, pages and visual look.

Where we’re at today

We have an early and limited proof of concept that includes:

Content import

Drupal + Feeds is a good way to test content importing and organisational questions about how we’ll deal with changes to source content, content review and allowing curators to add new feed sources.

Content creation

For now we allow editors and curators to create content in the content hub, but perhaps we shouldn’t and content creation should be import only, and the content hub purely deals in content review and metadata addition.

Content amending

Are you importing content from a team’s blog to reuse on the corporate blog? If so, you might find that writing standards and styles differ, so can you make the source blog adhere to the same standards or will you need overrides in the content hub? We’re designing for this.

Metadata management

Content is king, but metadata is the lifeblood. As mentioned above, we have some two-dozen fields around content quality, target audience and position within the organisation. It’s important to strike a reasonable balance between what is required and what you expose to which types of curators.

Integration with goals

We often use the Content-Action Model to help us better understand what our web pages are trying to achieve by breaking down goals, audiences and content. Our content hub integrates with this model.

Content discovery and export

Editors and curators will manage content, but page builders will need to access the hub to discover content for use. We’re building interfaces that they can use to query content and select it for export, as HTML `<link>` embeds or JSON.

Design pattern integration

The content hub is being built alongside a corporate redesign for EMBL. The new design will be pattern based and the structure of content exports will fit that. (What’s the point of a design library if the patterns don’t fit your content, or if your content isn’t designed to fit the pattern?)

Contextual previews

As content can be exposed with the a design pattern structure, we can easily insert it into boilerplate pages for true previews.

Page building tools

To lower the technical barrier for page building, we’re looking at creating interactive tools and WordPress-style widgets to drag-and-drop content into layouts.

What’s next

We’re sharing the idea wider within the organisation (this blog post is part of that) and gathering feedback on the concept, how it would be used and integrating that feedback on the usability of the system and decisions.

All of this is a starting point, a sort-of minimum baseline for a modern content platform. A content hub is something that will never be finished and needs to adapt and grow with the organisation. It’s a concept that is extendable and we’re looking at how to make more tools around in-context content previews and GUI-based page builders.

If this is something you’re interested in — even if you’re not part of EMBL — watch this blog, or drop a comment or email: ken.hawkins@embl.de

Diagnosing and remedying the problem

The problems are deceiving because they are each solvable — but often only individually, the fix to improve one will negatively impact a second use case in a singular system.

What makes it a hard problem is the underlying premise: a *single* unified editorial-curation tool is the wrong approach.

Having content in multiple places creates obvious issues around sources of truth and content reuse, but the problem caused by monolithic CMS that I’ve described above is initially harder to see.

And that’s why developers often get stuck with a rotten problem, they can only treat the symptoms that result from a hierarchical system. What’s really needed is a more flexible content flow, and we get that by separating concerns.

But the above is only a fraction of what we get by separating concerns, we gain far more when we need to target diverse use cases.

With a content hub as a bridge, management of complex relationships between items of content can happen independently of the authoring tools. The separation of concerns allows us to design each system to target the user needs.

• Content creators want to focus on writing or assembling imagery with as few distractions as possible;
• Editors and curators need to review content quality and add meta-information for content reuse and discovery; and
• Page builders need to discover content and export just what they need.

And those user needs map nicely:

As time progresses we can iterate on the user needs, tweaking each editorial system provide the better and bespoke authoring environment, creating tooling designed for managing content quality and relationships between content, and tools to select, assemble and export patterns* of content that integrate with the design system.

*aside: this configuration also lets us more easily leverage an organisation’s design patterns as templates for content export and previews. It paves the path for developers to stay on brand, and allows editors to get more contextually appropriate content previews.

Building it

The solution to this problem is not hard but it does require effort and it will involve integrating different platforms.

A singular off-the-shelf solution won’t be what you need.

At the start of the project we can avoid focusing on the choice for editor environments; we only need to ensure they can export structured data (RSS, JSON, XML, etc.), and virtually all contemporary content applications can do this.

It also means our content hub must be able to import structured content.

There are many choices out there, but there are a few topics worth detailing:

1. Think about standards, not software

Before you select a technological solution, be sure to document the use cases you need to achieve and the structured data you need to get there.

To cover EMBL’s use cases, we specified around two-dozen fields covering content quality, age, review, ownership and content placement within the organisation.

For us — and for many organisations — a content hub will be a customizable and extensible platform, and you’ll need to have web and UX to support the user needs of something this complex.

2. Import and export

Be sure to evaluate a platform’s ability to handle the import of structured data. How easy is it to add new sources? How do you want to handle changes to the source material? How are imports of content done?

Don’t forget to think about getting content out. How can you export HTML, JSON and XML from your system? How do you want to handle integration with your design pattern templates?

Most systems are quite good at getting content out and less easy to use when sucking content in.

3. Tools, platforms, useful things

I’ve avoided talking about specific software products so far, but ultimately you’ll want to Google around; here are a few options to get you started:

• Drupal + Feeds + Feeds Tamper:
  An open source option that is infinitely flexible but also has a maddening learning curve. Performance can be a concern on the content export side, so you may also have to heavily leverage caching or use an additional tool for content exports.
• Sanity.io:
  A commercial option that offers some slick developer and curator experiences. I’ve only used it a little bit, but I’d have concerns around managing a content import process.
• Contentful:
• A commercial option that is likely more to be a content creation tool, but it might also help you prototype your content structures.
• GraphCMS:
• A commercial option that turns GraphQL into a CMS. I’m not sure how well it would handle content importing and UX would be a concern for non-technical curators.
• Build you own:
• If you have in-house developer time, maybe just build your own application — but then you probably wouldn’t be reading this.

For EMBL, we have a background in Drupal and for the needs we’re after Drupal 8 is a clear choice for our content hub — at least for the prototyping phase.

Principles

And when you’re choosing your path, keep these three guides in mind.

• Build it for flexibility:
  Don’t put all your content into one CMS. Instead build a central “content hub” for the management, curation and distribution of content. Build separate systems for the creation of content.
• Design for needs:
  Don’t design the system by selecting vendors, design it by user needs and how users need to collaborate.
• Expect change:
  You’re building a platform and ecosystem. Not everything will launch on day one and needs will change over time.

Do you have similar challenges?

If this is something you’re interested in — even if you’re not part of EMBL — watch this blog, or drop a comment or email: ken.hawkins@embl.de