Why we rely on iiRDS and c-rex.net IDS for our blog
Initial situation
So far, our blog has been generated as static HTML from DITA sources. It was clear to us that this was only an interim solution.
Long before the release of a new version of our blog, we have been working to get our data structures and especially the metadata in our documentation and blog content on a good footing.
Our blog did not have a search function until now. With the exception of cross-references, there were also no relationships between the individual posts.
Metadata and relationships between content, products, companies or other stakeholders are essential in our view. Therefore, it was clear that the provisional static blog would be replaced by iiRDS and c-rex.net IDS in the future.
And we have now flipped that switch: The world's first blog system based on iiRDS is here!
Now you might be wondering why we don't use tools such as Wordpress or similar systems to write our blog posts?
Of course, at first glance, creating a blog with classic systems is the easiest way. But for us, there are a variety of reasons why we took a different approach.
(1) No silos - especially no external
If we were to use Wordpress, for example, it would be as a cloud solution. Our content would thus be in the cloud, in a - at least in detail - proprietary data format.
If you want to do something else with your rather unstructured information in parallel to the publication in the blog, this would involve a more complex data conversion up to a complex migration.
We now keep essential data in the cloud only as a copy, if at all, to reduce our dependence on systems. In addition, where possible, we also rely on available standards for our own data storage.
Consequently, the basic requirements are that the content is secured with us in a media-neutral, standardized format, so that outputs - and this could also be a publication to Wordpress - are always reproducible.
(2) Reproducible content
When we send our content out into the wider world through a publication, we want to be sure that this published content can also be published again at the push of a button.
A change to the editorial environment in which we create the content must not result in the content having to be touched (migrated) again.
Our system will continue to evolve. Much is not yet implemented in the current state and will be implemented gradually.
Possible new features depend on the metadata.
What changes are still to come for the publication remains to be seen. Whether, for example, the current issue with the gender terms will prevail and be preserved, only the future will tell.
We have tried to create our data set so that it is ready for the upcoming requirements for publication.
(3) Single source publishing with XML
Certainly, a single-source concept can also be implemented with Wordpress. After all, it's a content strategy to begin with.
For example, Andreas Zettl provides a plugin for Wordpress for output to PDF based on the Print-CSS approach, which can output content from Wordpress as a professional PDF.
But that is somehow not our world. As XML-Geeks, we prefer workflows based on the single-source approach based on XML - specifically DITA.
And since our focus is on technical documentation, the topics of automation and data structuring are part of our DNA. The DNA that is also needed in horizontal digitalization.
By using XML, we meet the first two requirements: not creating silos and being able to reproduce outputs at any time.
(4) Relationships between contents
Relationships between content are more than cross-references between individual posts.
It is metadata that establishes relationships between internal and external resources at runtime. The requirements go far beyond what a standard web CMS provides.
This can certainly be implemented there somehow as well, but is often not a standard functionality and must be solved via third-party plugins or custom development.
Our blog posts are a lot about us as a company and about our products. So it's not surprising that our blog posts also have something to do with product information or more generally with technical documentation.
And what could be more obvious than to use the now established iiRDS standard for metadata and relationships between content and products?
(5) Processes are the be-all and end-all
If we consider our blog as a kind of technical documentation, requirements arise directly from this area.
Of course, this includes translation, but also quality assurance via appropriate terminology management, valid and consistent data structures.
For this purpose, we had already set up appropriate processes for the technical documentation, which could and will be used without further ado when creating the blog posts.
In this way, we ensure a smooth process at the push of a button.
(6) Last but not least
And last but not least, it is important for us to live the processes in our everyday work that we recommend to our customers in projects.
Therefore, it is natural and profitable for us to use our own systems. Nothing is better for product development than being your own customer.
Conclusion
We need to start thinking about our content as part of the digitalization companies and processes.
Content hasn't just been cash since today. As a creative process, no artificial intelligence will create our content for us in the foreseeable future either.
It will therefore remain laborious, time-consuming and thus cost-intensive to provide valuable content for our customers and readers.
That's why we need to break down silos and not create new ones in the first place.
The basis for this is a Content Management System of whatever kind, in which the content is created and managed.
All resulting output formats, whether PDF or iiRDS, must be able to be generated reproducibly.
Even if we decide to deliver content for a different system or output format, this should no longer be a reason to have to adapt or even migrate our content.
For all of these reasons, we need a clear strategy for where and how content is created.
We see that the format landscape is growing right now. One reason is that developers are writing more documentation, which is why there is a lot of hype about Markdown and its derivatives.
In parallel, technical editors write their content in Word, FrameMaker or in XML structures.
Content is created in different areas based on different systems and formats. This can be quite useful.
However, the approach must become part of the company's content strategy so that clear responsibilities and output processes are defined.
This is not only relevant for publication.
Increasingly, we are seeing that once-established systems are dissolving, especially in the translation sector, and each area is doing its own thing here as well.
The consequence of this is inevitably a poorer, because mostly unplanned, quality of the translations.
Technical documentation has had all these processes around content creation, translation and publication under control for many years.
Use this knowledge and integrate other areas into these mature and well thought-out processes.
We will be happy to help you!