#The Era of Application Content
At Hygraph we’ve always had two stories. We’ve had the GraphQL story, the developer sweet-heart that is changing the way teams work with data. In that story we’ve been working with developers across the world to educate, support and provide resources for the larger GraphQL community. It’s a story we know deeply as developers ourselves and one that has been accepted with open arms across the world.
But there’s a second story for Hygraph. That’s the headless, content management story. One thing we’ve discovered time and again is that the idea behind the decoupled CMS is still as unclear as it was when first presented over a decade ago.
The content management story is defined. When the web was largely made-up of brochureware websites, digital yellow pages and list sites (proto-listicle), the CMS industry pioneered the way for programmatically generated pages. Take a database, take a template, mash them together and out comes HTML.
The headless CMS story is the next iteration of that. When we talk about a company’s digital touchpoints, it’s not just websites anymore. The portfolio of digital products at even the smallest companies include native experiences across mobile devices, automobiles, home speakers and more. In short, content on the web has moved away from being one-way brochure sites to two-way application content where consumers expect the ability to interact with your data and your business development teams want to observe those interactions.
The problem we see often repeated is that businesses both large and small still don’t fully grasp these changing expectations of their content. To embrace the vision of delivering structured content to any platform, we need to deliver content that is free from the opinion that any of the other platforms would like to impose on it. All too often we see companies embrace the idea of a headless CMS, only to replicate their existing website structure nearly identically in a headless CMS.
Don’t get me wrong, a headless CMS is completely capable of replicating any website structure. But that’s missing the opportunity a headless CMS offers.
The goal is not to simply replace one CMS with another one, it’s to deconstruct our content into the smallest modules possible so that they can be reconstructed into a wider array of possibilities. Think of this like reducing the springs, screws, bolts, and levers of your content into their atomic elements. A bicycle reconstructed at the atomic level could be a Ducati with enough vision and time.
#Using the Right Tool, Correctly
Maybe you’ve heard this joke before, but the lesson is applicable. Once upon a time, there was a woodcutter who spent all day chopping wood, sharpening his axe, chopping more wood, followed by more sharpening of the axe. It’s honest work but hard on the body and the throughput had hit the theoretical maximum. One day a friend tells him what he really needs is a chainsaw.
Intrigued, he buys a chainsaw and returns to work, and, to his frustration, the promise of the chainsaw falls through the floor. Productivity crashes. He’s even more tired than ever before and doesn’t understand why. He brings the chainsaw back to the department store and in a huff, hands it to the clerk and explains that the device must be defective because it’s not delivering the promise.
The clerk, wanting to help the customer takes the device, looks it over, and fires it up to see what could be wrong. As soon as the chainsaw roared to life the old woodcutter jumped back and yells, “What’s that noise!?”
It’s a funny story with a real parallel to how our customers approach their CMS. When the customers of our customers want a phone experience or a voice hub experience, the response is either to add another CMS or to try and adapt a content schema intended for pages to somehow support these new devices and then ask their developers to remove all the page features and transform them into a format for device-specific needs.
The third approach is to negotiate exorbitantly priced CMS contracts that do everything for you to support the state of the art devices - of last quarter and to support the next batch of devices, you’ll need to wait for the update (which you will pay for.)
We frequently encounter developers trying to figure out how to construct a menu or URL field in our CMS. These developers haven’t turned the chainsaw on yet. There’s a fundamental understanding of the changing nature of the content on the web we are trying to address, and help the next generation of content creators get ready for.
#The Emergence of Application Content
The underlying truth behind this change in our demands of content and the means in which we need to manage it is that content today is different. Content today is “application content.” Content needs to be interacted with, personalized, contextually adapted, and omni-accessible.
Reading an article is not just consuming content but informing the company what my interests are and what I find relevant. More than that, I want to be able to request the information in any number of contexts. Traditional content was a uni-directional distribution of information. Application content is a multi-directional sharing of information, interests, and ideas.
And whoever gets the recipe for application content correct will be rewarded.
#Types of Application Content
Examples of Application content are all around us. Generally, they combine any number of four types of two-way data exchange.
Passive Exchange
Passive exchanges are those where my interaction informs the content presented to me. The most common example of these would be “recommended for you” list sites, “most commonly read” or others where there’s a memory of the content visited. A number of the modern CMS solutions are able to support some form of these types of sites, though they are often limited to the pre-supported features. An un-opinionated CMS would allow for any metric to be collected passively.
Active Exchange
Another term for this is “user-generated” content. The most common types of these are forums, review sites or community-powered experiences. This is where the traditional CMS explodes. The most common instances of these types of sites either have to choose between insecure implementation or prohibitively expensive customization of the CMS. This occurrence is so common that the majority of user-generated projects don’t build on a CMS at all, even though they are, at the core, “content management platforms.” An open-minded, headless CMS can simply be designed to support this kind of content from the beginning, and not only that, be able to re-package the content for additional product ideas. A headless CMS would cut out the need for the custom development time and help you dramatically reduce your time to market.
Authentication Exchange
Authenticated applications, also expanded to the hot topic of “personalized” experiences are those where the content warehouse has a memory of who I am. A pure form of authenticated experience is “member only” websites where a login gateway sits between the content and the end-user. This is the current holy grail for content management. To date, no API based CMS is able to balance affordable with flexible on user authentication, even if they are able to support the feature at all.
Hybrids
In almost every permutation of the modern CMS-powered website, you’ll find some combination of the above. Supporting Application Content
So how does a modern CMS support application content? How does a modern CMS deliver mutable, multi-channel, and mono-manageable content to an industry-only accelerating in its speed of innovation and change?
We have a two-pronged approach: just enough opinion and robust APIs.
#Removing Opinion
We aren’t in the business of selling cake mix. We’re catering to a different kind of user. We are catering to companies that have their own bakers who are experienced, knowledgeable and are masters of their tools and recipes.
When you buy a bag of flour, it doesn’t come with a recipe on the side.
The same is true for our approach to a CMS. There is an audience for WYSIWYG editors, page-based schemas, and brochure-ware sites. Marketing is perhaps the greatest to blame for this stubborn hold-on to antiquated ways. They finally got their mind around producing for the web, they don’t want to be challenged by something new. If you know the cake-in-a-box will make a good enough cake, why bother with something new? Drop the idea for a content donut in the middle of a content-strategy meeting and watch the room lose their mind.
Customers are hungry for new and exciting, when marketing, product, and development work together, you’ll find the hidden cronuts inside your organization that you never knew existed. But it requires embracing change, removing our notions of a webpage centric platform, and allowing the bakers to bake.
That being said, we also don’t deliver a bucket of wheat stalks to the baker and ask them for a sourdough. That’s why we believe in “Just Enough Opinion” to supercharge your content with thoughtful CMS features and API enhancements that are tailored for this kind of Application Content.
#Robust APIs
In context of a uni-directional flow of content, the typical CMS has been optimised for reading of data. Even the earlier, primitive forms of the headless CMS still optimised for this singular flow of data with APIs heavily optimised for the read layer.
But what happens when data needs to get back in? The APIs become immediately more cryptic and unwieldy. From the beginning, when we decided we were going to adopt GraphQL as our only API implementation - we decided to go all the way and support both read and write. We were the first and still are one of the few to support GraphQL queries AND mutations. With the same descriptive query language that makes GraphQL so enjoyable to work with, you can enable interactive features of your content like never before.
But powerful queries and mutations aren’t enough. If your content can be accessed in multiple locations on multiple devices, there needs to be a robust mechanism for distributing which devices have access to which content. Modern content workflows need staging and the ability to work non-destructively with schema definitions and provide the ability to preview content in the context of the consumer device.
Fortunately, we support all of that with Hygraph. So what’s our next step?
#Our Next Steps
We are going all-in on application content. In a commitment to the future of digital creation, we have an aggressive timeline of features that will continue to empower tomorrow’s makers. Several of these features are not supported by any CMS on the market today and we are very excited about the progress we are making on them!
Even bakers get reference recipes. Here’s another area we are focusing on this year: better documentation. In phase one of our story, developers lead the way. The vast majority of developers were able to hit the ground running with our product with very little input. The GraphQL spec itself was actively evolving (and still is) so there wasn’t even much input to give! But we are stable now and have been for a while. The spec itself is now a member of the Linux Foundation and we are moving into phase two of the product.
This is the year you will see a lot more “how-to” examples and helpful resources, or "recipes", if you will. We’ve already seen companies like Apollo and Gatsby employ a similar effect by providing a “recommended” way to work with the content - to enormous adoption! (Side note, you can use Hygraph with both of those technologies!)
So, we still aren’t putting a recipe on the bag of flour, but we will also be producing some recipes if you need some brushing up on your baking skills.
The world of content is changing. The developer is enjoying a moment of freedom to work with cutting edge tools to present data in ways we’ve never seen before. Editors are enjoying a paradigm shift where their work is creating a generation of content-driven applications! And lastly, the devices that are consuming this content are growing at an ever-increasing pace as well with voice experiences, augmented reality, and virtual reality devices being just a few of them.
Content is changing, content producers are changing, come join us at the frontline, and push the boundaries of what content can do.