Authoring & Publishing Content in dotCMS

The premise of a content management system is to create and publish content. It always was and always will be. Managing content has changed significantly in the last two decades, putting content creation teams (typically in marketing) in the driver’s seat. They have tons of tooling that they can leverage (independently from development teams) to push their digital agenda—more on content editing experience.

Content management has many facets, but let’s focus on two: authoring and publishing content. When re-platforming, enterprises wish to improve operational excellence, streamlining the content operations and the overall time-to-market and time-to-value. What does that look like concerning content authoring and publishing?

Authoring

Content authoring has changed tremendously in the past two decades. As I mentioned before, it took an editor and rocket scientist to crank out web pages in the early 2000s. Those days are long gone. A key driver for simplicity (and more!) has been the evolution from page-based content management to content-centric content management. Separating content (and content creation) from content delivery is foundational in a modern content management system (CMS).

Key advantages of the create-once-and-publish-everywhere paradigm are omnichannel content distribution, lower content maintenance, and higher time-to-market. It has been a critical principle for several CMS vendors, including dotCMS, and is considered table stakes today. Let’s dig deeper into critical capabilities around content creation and authoring.

Content Creation

Assuming all relevant content types are defined and available to the content marketing team, creating content in a modern CMS has the following capabilities: 

Edit Mode (Anywhere) - Irrespective of the content presentation (headless, hybrid, traditional), every CMS should enable business users with preview (device type, language, persona), inline editing, drag & drop, personalization, and page template editing. Don’t settle for less in the core of your CMS, and edit content anywhere. 

Block Editing - Creating nested or alternating content blocks is a more intuitive and modern way of creating content and streamlines your content creation process. dotCMS ships with a native Block Editor.

Tagging, Taxonomies, and Relationships - Content is useless if it can’t be found or exposed in personalized content delivery. NoCode tools to tag content, create relationships between content types (e.g., article and author), and set up taxonomies that drive the findability of your content.

Collaboration - Delivering a digital strategy is a team effort, and delivering highly engaging content is no different. Any enterprise CMS will offer capabilities to review content drafts in preview or side-by-side as a content editor before passing on to the next step in the content approval workflow for that specific content type. Downstream, contributors can review and provide feedback and either reject or approve the draft before publishing.

Bookmarking - Enterprise CMS solutions offer capabilities to access often-changed pages and content items faster with bookmarking. It allows content authoring teams to make changes quickly and drive time-to-market and time-to-value. dotCMS supports bookmarking out of the box.  

Content Governance

Don’t sacrifice governance over quality or time-to-market. It will fire back at you one way or the other. The good news is that an enterprise CMS like dotCMS can help you streamline content operations, meet all your governance needs, and still be agile in your go-to-market motions.

The type of content can be subject to different governance, where legal & compliance will probably not be engaged in blog posts but want to approve terms and conditions on the public-facing website. In a multi-site/multi-brand set-up, it’s common to have a centralized content team for corporate content, and the decentralized teams will drive the brand content.

The foundational support for any content governance is a flexible and enterprise-grade workflow management capability like dotCMS offers. The content creation process is usually not restricted to just internal resources, and there is the notion of extended governance: external resources being part of the content creation process, typically agencies. The CMS must also support these “extended” contributors (see next section). Building custom content approval workflows to support the corporate governance model should not be a coding effort; it certainly isn’t with dotCMS. 

Front-end Authoring

There are content management use cases where the content contributor doesn’t need access to the CMS's back-end nor the complete content authoring tooling set. A good example is a franchise organization: the franchisees want to manage their franchise data (business hours, addresses, contact details, promotions, etc.) for one or more locations. Or people in the field just need to capture local data. Both scenarios would qualify for front-end content management, where it’s usually a minimal set of straightforward content types that must be managed. Users can change or add new content without accessing the CMS back-end via a simple interface. 

Content Publishing

Creating and managing content is one thing; getting it out to the world is another. The publishing process can put a lot of restrictions on the content marketing team if it doesn’t have the flexibility and independence it needs. 

Publishing flexibility

Content Management Systems have been around for a couple of decades, and while this may have been the case in the early 2000s, publishing content to a live / production environment should not depend on developers, a specific time of the day/week, or be subject to any other restrictions. Speed is the new currency, and content editors need to be empowered with the following:

• Instant publishing: Content will be live on the production environment as soon as it is approved in the approval workflow. No delay or wait until a specific day/time. 

• Time-based publishing: Content marketing teams like to front-load the work regarding campaign-based content and want to bundle content/assets well in advance and schedule the publishing for a specific day/time (and potentially take it offline automatically after the campaign has stopped). 

• Volume-based publishing: Publishing content usually doesn’t happen one at a time, and in many scenarios, content editors want to “bundle” multiple content items and publish them simultaneously. The ability to publish content individually and in batches provides maximum flexibility & agility for content editors.

Independent Publishing

In today’s day and age, enterprises have multiple digital touchpoints to engage with their audiences, and they are all content & data-driven. Any modern CMS can handle multi-site/multi-brand platforms. There is no reason to have multiple CMS solutions for each web property to publish content on those apps independently. Having multiple CMS’s creates content and experience silos and is budget unfriendly. In addition, it prevents the reuse of content and creates inefficiencies. A multi-site and content-centric CMS will support global (reusable) content with local / site-specific content that can be managed independently. Next to flexible content approval workflows and permissions, content teams can work independently to create and publish for their website as they see fit, respecting the content governance structure and being as agile as they want in their time-to-market. 

Omnichannel publishing

As mentioned above, it’s not just a single website enterprises have to manage, it’s a multitude of channels their audiences want to utilize to engage with the enterprise. Creating and publishing content across multiple channels efficiently is critical for the digital enterprise. Content-centric and AP-first CMS solutions, like dotCMS, support omnichannel content publishing. 

Single/Multi Publishing Architectures

It is not uncommon to have multiple publishing architectures, meaning environments and chains of environments that are strictly separated for designated applications. For example, have a dedicated architecture for internal-facing applications (such as an intranet) and one for all the public-facing websites. Reasons to separate publishing architectures are usually a combination of security requirements and scalability/performance.