This is not an article about new features that we will implement or the value which DoX can provide.
This is merely a personal overview of my experiences with DoX CMS from both sides of the screen.
If your interest thus lies in how different users utilize our system, you may find this piece useful.
A different mindset
Before I joined the DoX team, I was used to your usual text editors where you can fully and directly determine how to format your work. As an example, my CV has a dark column with light titles that runs along its left-hand side. This column separates these titles from the contents which use the standard black-on-white format for formal documents.
Now, I had certainly done my share of independent study on the principles of structured documentation. Despite that, the switch to the actual practice of simplified content editing and separate style sheets was rather startling.
I can thus certainly understand why new users may initially expect DoX CMS to handle like MS Word, for instance.
When you can directly finetune the formatting of documents, you may make it into an artform.
Compared to this level of control, to then feed the fruits of your labour to be crunched together by a blind compiler instead almost feels like a crime against humanity.
Yet, at their finest, the results of this process resemble generative art. That, too, is a form of art despite how its beauty is of another kind compared to hand-crafted creations.
When generative art is beautiful, its beaty is akin to that of nature: structures fit the available space perfectly in the absence of the editorial touch of a brush or a chisel.
For this reason, I have found what DoX CMS might afford in this latter sense fascinating from the start.
As such, I will provide some examples of my observations below.
The ecosystems of content
As the one responsible for user support for the platform, I sometimes feel like a reef diver.
I possess the privilege to experience firsthand the full variety of the forms into which the same baseline system settles.
Exactly as with either nature or generative art, the initial conditions largely determine the available trajectories and the associated results.
The most startling discovery from this perspective has been just how differently different users utilize the same system to make it their own.
Instances built around teams of writers often have a highly developed workflow system. Such systems tend to include additional revision states that help bounce content back and forth, for example. Not all such states have to involve delegating responsibility, either. Sometimes, they have other functions such as differentiating between approved and published content. Having been forced to focus on their workflow, these users have also been able to utilize it in other ways that help with content production.
Similarly, an instance with only one user may become a personal nest where that user is free to shape the system to reflect their specialization. During one initial training, the sole user of an instance was someone highly skilled with technical drawings. As I was introducing the system to them, the emphasis shifted to functions involving images such as how you can add localized images.
It will be interesting to observe whether this person will now also make variables for re-used standard images, for example.
No matter how fascinating such diversity may be, its existence also emphasizes the presence of a specific issue.
Namely, the best procedures for how you can combine features or apply them to practical needs are overall less than obvious to the totality of our users.
Any innovations in one instance reach another one only incidentally.
To remedy this issue, I already added a new section to our user manual, and it contains several basic guidelines to utilize the features of DoX CMS to their fullest potential.
I will also develop our user training to include these practices which combine several systems to handle practical challenges when writing technical documentation.
In the depths of the system
On a basic level, DoX CMS is a decently simple system with a clear majority of the functions one can reasonably expect from software for technical writing. There will always be the next part in need of further develioment but I cannot name any fundamental shortcomings based on my personal experience.
Such seeming simplicity may mislead, however.
Just under the surface, there is surprising depth to the system.
The reason for this lies in how the various features of DoX CMS are constructed in such a way that they can be mixed and matched with an unexpected level of freedom. As a result, each feature possesses more applications than you can readily conceive should you only observe them one at a time.
For example, the current revision state of a topic is used as an identifier which you may designate in a style sheet.
When I realized this during my inventory of such identifiers, my mind immediately went to the possibility of adding rules to highlight content which has not yet been approved. You could add a distinct background color to the revision states for topics that remain work in progress. In this case, anyone who were to browse a draft of the publication would immediately detect these parts. They could then check whether said parts are ready for publication. This would further reduce the risk of unfinished content being used for the final product.
I also noticed that one customer’s instance included embedded variables. They include a publishing variable inside another variable. This other variable then also contains all the standardized content around said information such as the copyright symbol. As such, this information need not be written each time in topics or as part of the value for the publishing variable.
Another customer’s instance includes a variable with content that has been conditioned with tags related to different stages of production. This makes different drafts clearly distinct based on this addition to their cover pages. The final version only adds an empty phrase element which leaves that part of the cover untouched.
There are other examples such as my own experimentation with element classes and the additional commands that DocRaptor enables. For now, I will not discuss them further, though.
Some of these findings are also collected in the new version of our user manual. For example, I have tried to list the most important identifiers that you need to write style sheets. I also added a list of recommended procedures at the end of the manual.
We shall see what will surface after the next dive.