Do you work a lot with tables in ST4? I hardly dare ask this question. Whoever uses an content management system such as ST4, needs tables in many contexts. In user guides at every turn – and equally often in data sheets, spare parts catalogs, and service manuals.

I’d like to show you today what options ST4 offers to manage data that (possibly) should appear as a table in your information product. There is no ideal way to do this. But there is a great deal of bandwidth for your authoring needs.

This much in advance: Nobody is forcing you to manage “table-like” data in ST4 as fixed tables. But let’s start from the beginning.

Our Example

Let’s have a look at an example. We’ll use a table which lists accessories for a technical product. This is a typical example for a user guide. Here is the table with its completed layout for a printed manual in ST4’s layout preview:


The Classic Solution – A “Real” Table in ST4

The simplest option for managing this table is to create a “real” table with the data in the ST4 editor. This is easy to do with the table features:


With this approach, you determine in ST4 that the data will appear as a table in the final product as well. And you hard-code the data into the table.

Since ST4 2016, you can modularize tables. This is possible with the so-called structure fragments. Which means, practically speaking, that you can split a table row by row into reusable units. This is an effective method to systematically standardize tables and to keep them manageable. In our example, this is what it would look like:


Still a Table – But Dynamic Content

The following solution goes one step further. You still define the data structure in ST4 as a fixed table. But you don’t hard-code the content in the individual nodes. Instead you link it dynamically from ST4 data nodes.

We call this table variant in ST4 accordingly a “dynamic table.” Take an empty fragment, click on it and choose the following option from the context menu. You can do the rest with the help of a wizard.


This approach has obvious advantages: if the values of the source (the data node) change, the content of the respective tables is changed automatically as well. In contrast to the classical solution, you don’t have to manage the changes manually for each table.

Here’s another solution from the “dynamic content” category: With the mechanism for the maintenance tables, you can have ST4 generate tables from metadata that belongs to any text node. This solution has been implemented fully functionally, so that you can easily use it. This can be done for typical maintenance tasks, but also for any individually chosen metadata.

Completely Dynamic – Row and Cell Content as Individual Nodes

There’s more than these two ST4 features for tables. ST4 provides the option to no longer manage “table-like” data in tables, but in the form of individual nodes.

What would you need this for?

Let’s look at a scenario. You want to publish our example from above in print and mobile formats. A fixed table structure will quickly present problems. In cases where a table would be ideal for a print publication, it won’t work for mobile, e.g. because it’s too wide or too complex. For mobile, you’d prefer to present the information in a linear format with expandable areas. This means you need completely flexible information structures already at the data source in ST4.

For our table, this could look as follows. You represent the relationship of the data in the node structure. Instead of thinking in table logic, you concentrate on data set logic.


For each table cell, you use a separate node. And for this node, you use reusable fragments. This creates modularization down to cell level.

Of course, you don’t have to take modularization down to cell level. The following scenario 2 shows a solution, in which one node in ST4 represents one table row:


This approach allows you to structure the table semantically as well. Use a certain information type for the different rows or columns (e.g. always cell 3), or store metadata in the nodes.

Where are the data values? For the table headers, these are in the metadata of the root node “table.” For the rows, the values for column 1 and 2 are in the metadata as well. For column 3, it’s in the content of the row nodes. This is because the mixture of multiple and different paragraphs can’t be represented by metadata very well.

The customer’s goal in this case was not to optimize the output page, but ease of use in ST4. This method allows him to put together tables via drag-and-drop.

But how can you create – if needed – a table again from these information structures in the completed information product? That’s an easy one for ST4 these days. The Page Layout Designer for print layout can create a table from any regular data structure, as long as it’s possible to recognize what you’ve defined as a table or table elements. This is possible to do e.g. via the node class or, as shown above, via metadata.

The Online Media Designer works the same way. It can present the same data from the system as a table, or treat it completely differently, by e.g. transforming it into sequential, expandable areas.

One more time, with audio and video? Have a look at our webinar on tables.

This concludes our roundtrip of table handling in ST4. As you can see, our content management system offers full flexibility of data management. And this allows you flexible interpretation or further usage of your ST4 data in your output.

This is important for the mobile world. And this is important for all authoring processes which trend towards Information 4.0.

Here in the blog you’ll also find more reading material on tables, e.g. on automatically generated tables.