The workflow that I have in mind would work somewhat like this:
One of the requirements is that the CMS works well with Confluence without any heavy coding or extensive configuration. CCMS would be preferable over a regular CMS.
Any ideas would be greatly appreciated. Thanks!
Could you explain the use case? Confluence already has a database, so not sure why you would want to store data in an external database. But maybe I am missing something?
I could see authoring content in Confluence, then publishing/pushing that content to the web, basically using Confluence as a sort of staging server.
For example, there is on commercial plugin that does just that, push from Confluence Cloud (ugh) to WordPress (double ugh): scroll-wp-publisher
I think I am too - Confluence is a CMS you write stuff you want to put straight in front of people, and encourage them to work with you on creating and updating it. The description in the question is of a publishing CMS that uses Confluence as an editor (and hence loses or duplicates Confluence functions pointlessly elsewhere)
I think I need to see the use case too, as my instinct here would be to choose between
I just don't see the point in having two!
I was hoping there was a third-party solutions that would allow us to create and manage content in topics or smaller blocks as the basic unit (component content management system) inside of Confluence. We need that level of modularity to take advantage of some functionality that we need (versioning per topic or component not just per page, multi-channel publishing, easier reuse to minimize rework and minimize translation cost, easier re-purposing, searching by content tags not just plain keyword search, tagging of content blocks so they appear only for certain customers or product model or regions or a combination of these types of variables, topic- or component-level review workflow not just per page, update a topic or component once and that same content gets updated in all spaces and docs across the organization, build a hierarchy of Q&A content for chatbots, etc.)
Since most of our content is already in Confluence, and our writing team is already familiar with authoring in Confluence, we were hoping that we could continue to use Confluence as our primary authoring tool, write the content in a template or form that is automatically tagged in the structure that we need (DITA or other XML doc format), store that data in a CCMS (not just a CMS or doc repository), and then process the stored contents to our requirements (publishing, translations, search, etc.)
I guess making Confluence work like a CCMS is too much to ask. Confluence is not designed for that level of processing and automation. It seems that the direction to take is to really use a CCMS. Confluence can remain our main tool for less-structured content.
I agree with everyone saying that having Confluence and a CMS on top of it does not make sense. However, using Confluence as a complete CMS is kind of what we are about at K15t, but our app focus is mostly on Confluence Server (not sure which one you're on).
Have you considered just using pages as the basic unit and using Include macros to combine them into pages that are entire articles? There are no limitations as to what pages can be included, they can be one character or image or video or anything, really. They can be included inline, too. I have written a blogpost about this last year that talks about this approach in vanilla Confluence (Cloud).
If you want to go further and also use versioning and translating of topics, as you mentioned, Confluence Server is where it's at. Our apps Scroll Versions and Scroll Translations introduce space-wide versioning and language management and come with an extended Include+ macro that respects versions and languages when reusing snippets.
A problem that I think is currently difficult to address is the structuring part, as there is no hard structuring functionality in Confluence. One can use page templates that create some structure at the beginning of the authoring process, but you're free to change it after the initial page creation.
Actually, we have a microsite where we collect knowledge about Confluence functionality and apps that help using it as a CMS for documentation. You can check it out here and here we talk about versioned content reuse specifically.
@mark.dignadice, it sounds like the classic use case for a true CCMS/DITA/XML environment if you want to have such structured authoring. You would have to push Confluence out of its comfort zone to having 10,000s of pages to get your module-level versioning, or change your goals and move to some sort of markdown to allow authoring of many modules on a page (plus engineering to make it all work).
As an observation, your user base is going rebel if you move to such restrictive environment as structured authoring (DITA/XML) -- it is a huge sea change that often takes a year to implement. I would suggest relooking at your requirements to see if they can be molded to Confluence rather than the other way around.
Thanks for all your inputs. Our business requirements (all mentioned in my second post) necessitates moving a lot of our content to a CCMS, it seems. Yes, it will take a lot of work and resources to pull off. But I've seen it done successfully before (Word to CCMS, Unstructured FrameMaker to CCMS). Besides, I don't see why we should rework our business goals to accommodate the restrictions of our current tool. Don't get me wrong. We are very happy with Confluence. It will remain as our main tool for authoring and publishing internal content. It just doesn't meet some of our needs.
I guess my next questions would be: Is there a functionality in Confluence that will allow us to export content into DITA or other XML formats? Is there a 3rd-party tool (CCMS) that can import Confluence pages for re-authoring into XML structures? I'll post this question as a new thread.
The biggest problem which Confluence can't (surprisingly) accomplish even with plugins is:
How to connect / automate / publish application code documentation for developers created by developers with application documentation for users created by technical writers.
It looks like BookStack is better for that ;)
But I can't be sure since even Confluence team is not able to provide best practice for Technical documentation workflow (from application to the reader)
Correct me if I'm wrong.
Hi @mark.dignadice. Encountering this thread after almost two years, I'm curious to know if you have been able to implement the workflow you had in mind and posted about at the top of the thread and also find answers to the questions you posed in your final post? As a technical writer at my new company, I also want to hopefully use structured authoring and DITA for our documentation, which at the moment happens without much structure or a centralising system on Confluence (and across scattered Jira issues).
Hello Community! Quick disclaimer: We are running a contest on Community (The Atlympics!) from July 23rd - August 8th of 2021. If you are interested in participating in this contest (prizes! ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events