For many years web publishing has been synonymous with Content Management Systems, a stack of templates, administrative screens, and data models that were deeply intertwined. This interdependence begat monolithic approaches to editorial workflows and has hampered innovation and interoperability.
To achieve the kind of simplicity we demanded from our authoring and management tools, it became clear the biggest hurdle was designing a system by which content was freed of its final form. If your content is stored as HTML, all you will ever be able to use it for is a web page that is renderable at a specific point in time. That means that the first responsibility of an authoring tool is to generate markup, not provide an environment where impactful creative work can take place.
Our tools had to instead work block by block, understanding that content on the web does not necessarily live inside a browser, nor is it just a standing wall of text. Our API was designed from the ground up to understand every element within content as an independent entity with its own history, and arrange these elements in any number of semantic roles. In one place, a video may be part of a blog post, in another a segment within an episodic series. There should only be one canonical reference for this element of content, regardless of where it exists.
Our approach to platform development means that the Content API can do things that no other system can do. Some examples:
Because content on Marquee is just pure structured data, it can be reprocessed in any number of ways without additional input from the original publisher. It doesn’t matter if you’re targeting desktops, tablets, smartphones, set-top boxes, or devices that haven't been invented yet, content managed through Marquee will just work, without ever needing to be migrated.
Since content is just programmatically accessible data, designers and developers don't need to work around predefined markup structures. Every element can be queried for semantic meaning and used in service of the most complex layouts imaginable. That means that instead of fighting with templates, your team can focus on creating immersive app-like experiences in a fraction of the time.
Early on we were fortunate to speak with a number of large, legacy publishers and learned one of the biggest challenges they faced involved sharing content between several different, ingrained internal platforms. So we designed the Marquee API to be highly decoupled, allowing custom adapters to easily be built for integrating Marquee-generated content into even the most advanced in-house systems. The API also allows for receiving content from different applications, and is not just limited to the Author as an input. The key idea behind the Marquee toolset is being able to adapt to the editorial needs of the content.
As a company that has always placed a heavy emphasis on engineering, we realized that interoperability was of huge importance if we were going to win over both independent and in-house developers. All of the code we’ve written for interacting with our API, building sites with Marquee content, making those sites blisteringly fast, and creating intuitive interfaces is not only available as open-source code, but we have abdicated all ownership claims over them by releasing them into the public domain. Using Marquee means that your content is always accessible, always portable, and always yours.