It is fitting, during this chilly winter period, that today’s post is about deep-freezing content. This is how we like to describe SCHEMA ST4’s release function in our training courses. But what is behind it? And above all, what do you get out of it? This hot topic (to stay with the metaphor) is what I would like to reveal a little bit about today.
The basic principle – defined, retraceable versions
As soon as you release a content module in ST4, the version is labelled with the time of release in the database using a special version number or a text label that you can individually define. If at a later date – perhaps several versions later – you need a previous version once again, you can access that exact version of the content module.
This releasing and versioning process works with all types of content modules in ST4; text modules, resources, variable nodes and of course projects too. So, if you are currently working on version 11 of an operating manual for a product, you can still access version 2 of the document at any time.
Let’s go through the whole process using an example. Let’s say the following module has just been created for the first time. It’s a warning notice, created in a fragment that has consequently not yet been released:
When this module has reached a certain stage, you can set a release. This is easy to do using the context menu:
The module is now marked with a tick. This gives this exact version a special label in the database, so that you can go back to it at any time.
The standard ST4 system (ST4 DocuManager) offers two release levels: release and approval. If an information module has both these releases, it is marked with two ticks.
As mentioned earlier, this process works for all types of information modules. And so that you can also keep on top of versions in large databases, there are special management functions in ST4 that reliably aid your work, including the Version Browser and Release Report (see graphic).
How our customers use releases
The appeal of the releasing and versioning mechanism lies in how easily it allows you to archive data in ST4. In contrast to file-based methods, archiving does not create any redundant data.
When I think about our customers, they mostly use releases in three scenarios:
Scenario 1: The “simplest” (in quotation marks) case is when releases are required for aiding internal work processes. If, for example, each version of an operating manual that leaves the authoring department (forwarded internally to sales, externally for translation or ultimately to the customer) needs to be saved.
Scenario 2: In this scenario, releases are indispensable from the point of view of technical processes. This relates to authoring using content processes, which automatically compile documents, as it is only possible to differentiate between usable and locked – because they are currently being edited – content modules with the aid of release information. And only using versioning can manuals for different versions of a product be compiled – automatically, and so without interventions from a technical writer.
Scenario 3: In this scenario, I have our customers from the pharmaceutical industry in mind. They have to account for and make transparent every change they make to a module, e.g. for a package leaflet managed in ST4, for regulatory compliance. Traceability and electronic signature are the key words associated with this – unthinkable without the combination of releasing and versioning, and easy to achieve with ST4.
Our tip – plan well and try it with a test database
As you can see, releasing and versioning are important components of managed content processes. They allow you to effectively support your authoring processes, even when working with standardised and recurring processes.
If you have gone without clear-cut releases up to this point and are planning to implement this powerful feature, from my experiences with many customers’ projects, I would recommend the following.
First consider as a team, which versions of your process you really want to “freeze”. From a technical point of view, ST4 can support almost any degree of complexity, but it is always good to keep things simple and streamlined.
Test your concept, step by step, with everyone involved. When will each release be used? How should the labels for identifying the versions be created? How does it work with the version browser and release report? And most importantly, don’t use any real data for this test, rather a specific test database.
If you would like, we can provide an experienced advisor and guide for updating your authoring process in this way. The advisor will work together with you on the concept and train your team on its safe and efficient use.