
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 itOrganisations 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 todayWe have an early and limited proof of concept that includes:
What’s nextWe’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