The more I use DoX CMS, the more convinced I grow of the notion that the implemenation for controlling different views is a major strength of the system. This implementation does benefit from practice and anticipatory content management, though. These articles on the ‘secrets’ of the system are not intended to become a series. However, I still decided to share good practices for controlling views as another such article. The underlying concept is the same as in the previous article on the secrets of controlling translations.
The first subject that I will discuss the core principles for controlling views. This part focuses on filtering content. Next, I will specify values associated with different views and how to use them to support controlling said views. At the end, I will also touch on planned development that will further help with controlling specific views.
The Core Principles of Controlling Views
All different kinds of content in DoX CMS are shown on separate lists. Topics are shown in the master topic tree and the revisions of publications on the list of publications. What content each such view shows can be almost entirely be determined by users, though. The core functions responsible for this are specified below.
Column Visibility
Each list that you can control like this lets you select which columns to show. As will be detailed below, any such column can be used to filter content.
The list of available columns opens when you click on the icon in the top left corner of a list view. You must click on the name of a column on the list to toggle its visibility. This hides columns that show and shows columns that were hidden. The box by the title of a column has a check when the column shows.
It is best to consider in advance which columns will be needed in your personal interface. Showing unnecessary columns as part of the default view hinders usability. The different available columns are useful for different ways to employ the menus.
For example, the Topic ID column in the Editor menu is vital to add and then track internal links. We recommend that everyone keeps it visible for this reason. Should you contact our support about an issue, it is also important to help us identify any related content based on unique identifiers such as topic IDs.
Revision number, on the other hand, is generally not as relevant. If content is undergoing a major revision, though, this value can be vital to differentiate between content that has already moved to the next version (from 1.xx to 2.00, for example) and the rest.
Column-specific Filters
The primary means of controlling content shown in DoX CMS are column-specific filters. Each column lets you control the view through a filter based on its contents, and several such filters may be applied simultaneously.
When you move the cursor over the title field of a column, you will see a text field. When you click this text field, you can write in it. If the column in question may only contain predetermined values such as usernames or tags, the system instead shows a list of available values when you click this text field.
There are also arrows pointing up and down to the left of the text field. When you click them, the system rearranges all content based on the values of that column in either ascending or descending order. The first click makes said order ascending. The second click shifts it to descending. A third click reverts the view to its the default order. The active ordering principle can be identified based on which arrow is emphasized. Should either option be active, the related arrow will show even when the cursor is moved elsewhere.
You can, for example, only show topics which are in their open default state and have specific tags from tag categories of your choice. Such categories may also be added for listing remaining required operations such as updating images. You can also select a set of tags associated with a specific publication if all topics in that publication include them, and only see the content associated with it. This option requires you to consciously apply tags in a manner which enables such actions. It will not function properly if, for example, some content only has tags on its elements or if several publications involve the exact same combination of tags. In the latter case, you may have to add further filters based on details such as keywords in topic descriptions.
Find in Content
The Editor menu also allows you to control the view based on the contents of topics. This function processes the source XML of topics and thus allows you to use terms such as the identifiers for element classes to find the topics that include them. Such a content-based filter can also be combined with column-specific filters.
You apply this function by writing in the Find in Content fileld on the upper right corner of the Editor menu and then either pressing Enter or clicking the magnifying glass icon to the right of the text field. You remove this filter by doing the same while the Find in Content field is empty.
This content filter does not let you search for long strings of text. Instead, spaces between words tell the system that the topics must contain each of the words thus separated. If you use the character ‘|’ between terms, the list will show all topics that contain at least one of the terms thus separated.
The terms ‘type=”warning” shock’, for example, would make the master topic tree only show topics with warning notes and the word ‘shock’. The terms ‘type=”warning”|shock’, on the other hand, would make the master topic tree only show topics with either warning notes or the word ‘shock’.
Other Features
The toolbars for different menus also have other commands that help you navigate those menus.
The Next Selected command shifts the view to the next item on the list that is currently selected. If you select an item while a filter is active and then remove the filter, this command lets you immediately return to said item. Should you select several items while a filter is active and then remove the filter, you can use this command to move between the and to locate each in the unfiltered view. This option is useful when, for example, you must ensure whether topics with specific tags are placed correctly in the master topic tree.
The Collapse All command hides all sub-content. You will only see items that belong to the first level of organization such as the newest revisions of publications and tag categories. Since the list of visible items will be shorter, you can more easiy locate specific positions on it. Meanwhile, the Expand All command shows every item on the list on demand. You can also show the sub-contents of specific items by clicking on the plus signs next to their titles or hide them by clicking corresponding minus signs.
Controlling Specific Views
The means to control four specific menus are discussed below. These menus are (1) the Editor menu, (2) the Tags menu, (3) the Publications menu, and (4) the Translation Projects menu.
Editor Menu
Using DoX CMS mainly involves the Editor menu which almost invariably has the largest number of shown items. However, the Editor menu also contains the most options for controlling its view.
Columns with Custom Values
You can utilize at least the Description, Revision, Revision Comment and Tags columns as helpful filters. These columns are united in allowing users to control their contents to a degree.
The Description column shows the contents of the Topic Description field. This text field is available at the bottom of the text editor when you open content in it. You can use it to write details such as keywords that are unsuited to be made into tags. Examples include the names for components: screen, exhaust, scoop, and so forth. You can also designate the topics with the source elements for conrefs like this, for example.
The Revision column shows the revision numbers for the active revisions of topics such as 1.00. It is generally not a good idea to try and coordinate the decimal values of revisions as updating individual pieces of content as needed is a core function of structured authoring. Changes in integers should be saved for more comprehensive changes in versions. Doing so lets you use the column to either show topics that have yet to be updated, alongside other filters, or to only show the topics that will be used in the next version of the publication.
The Revision Comment column shows the values for the Revision Comment fields in the active revisions for topics. This field is intended for you to describe the changes between revisions. If these descriptions include standardized phrases, you can use this column to only show the content where the latest update is some specific change such as the implementation of conrefs or variables.
The Tags column shows the tags applied to the topics. It does not show the tags used on elements inside them unless the same tags have been used on the topics themselves. You may also specify tags separately for each tag category. Filters based on tags let you show the content related to specific publications if all topics have the tags appropriate for their intended uses and each publication has a unique combination of tags. You may also add new tag categories for tasks related to the internal management of the system such as the actions required by pieces of content.
Folders
Folders for topics are themselves topics under which other topics have been organized. Such topics need not be included in any publication. They can be left empty, save for the title that shows on the list.
It is best to use folders based on subject matter rather than the organization directly tied to any publication. The content structures for individual publications can be built later using topic trees, and incorporating them to the master topic tree hinders reusability.
These topics can also include details that help control the view.
In addition to the Topic field and the Description field, you can write metadata and keywords in the content of such topics to be used as folders to help find the correct position with content searches. Once you have filtered content to make it easy to designate, you can select it and then remove all filters. When you remove filters, the view stays in said position. If it moves elsewhere, you can use the Next Selected command to find the correct position again.
Tags Menu
The contents of the Tags menu can also be reorganized. This option can be used to make further management easier.
There are different ways to reorganize content in response to different needs.
The order of the tags on the first level of organization, which also act as the names of tag categories, also determines the order of these categories in other tag-related menus. Thus the most important and most encompassing tag categories can be placed on top to emphasize their relative significance and intended order of application. Closely related tag categories can be kept in sequence and isolated categories such as aids to content management can be left at the bottom.
It is also possible to organize the most commonly edited tag categories, to which new content is added regularly, on top. This reduces the need to browse through the list each time that new content is to be added to them.
Alternatively, the smallest categories can be placed on top because you need not scroll as much to skip past them. If general categories consist of few options such as types of publications and the the majority of choices such as the components involved are specified using further tag catagories, this method can be combined with the first principle discussed above.
Publications Menu
The primary means of controlling the Publications menu are the Name, Description, State, and publishing variable columns.
Unless the value of a publication’s Name field is used in the publication itself through the associated system variable, you can embed identifiers to it to help control the view. This value is also used to determine the initial filenames of published files. As such, it can be a good idea to embed language identifiers and the like at the tail ends of these values.
If the Name field cannot be used for keywords and identifiers, they can be added to the Description field. Alternatively, the Description field is a good place to add revision comments for publications to comment on the updates between revisions.
The State column specifies which state of the workflow a publication’s revision occupies. Ideally, only the newest revisions should be in the Open state. As such, this column can be used to hide older revisions to support other filters.
The Publications menu allows you to show a separate column for each publishing variable in the system. These columns show the values for these variables in publications’ revisions. In principle, the values for such variables can be used to control the view even when they are not included in publications’ contents. You can, for example, introduce publishing variables which are only ever used to control this view by specifying their values for different publications in a way that helps filter the view. Such variables can be distinguished from other variables in ways such as adding a prefix like ‘COL_’.
Translation Projects Menu
When you send content to translators, the Translation Projects menu receives a corresponding item. The most primary means of controlling this menu are the Name, Target Language and State columns.
Similar to other menus, translation projects also let you use their names as an aid for controlling the view. The name of a translation project is specified when you first initiate the translation request. Because this value is also used for the filename, it is a good idea to also add details such as the target language’s identifier to it – especially when you must handle translations in several languages at a time. When you do this, the Name column can then be used to swiftly locate the correct translation projects.
Unsurprisingly, the Target Language column shows which language the translation will contain. This value cannot be controlled past that but when you use it as a filter, you can see all translations to the specified languate side by side to compare them. It is also helpful when combined with other columns when the other columns do not contain sufficiently specific values.
The State column, on the other hand, tells whether the translation package has been imported. In other words, you can elect to only show open translation projects to see which translations still need to be uploaded.
Planned Improvements
There will always exist a need for further development and controlling views is no exception. Should users request new columns that would benefit them, for example, they will generally be simple to add.
An obvious addition to the Editor menu is a column that tells you whether the active revision of a topic is its newest revision. This only requires comparing two values to determine a binary choice between yes and no. This column will make it easier to track which content has had its active revision changed without it then being reverted.
The Publications menu would also benefit from further options for filters as some producers may require unique publications for each delivery. These include Tag columns similar to those in the Edtor menu.
The Edit Publication menu currently shows the same columns as the Editor menu but lacks a toolbar. To improve this menu, we intend to add commands such as previews of the selected revisions. At this time, doing this would require a separate tab to use the Editor menu. A toolbar could be added to support such commands in this menu. An alternative that we are also considering is to embed the buttons for such commands inside new columns that you can control.
The Edit Topic Tree menu is planned to let you recycle content structures by dragging and dropping contents from other topic trees in addition to the master topic tree. Currently, reusing structures from other topic trees requires using copies of those other topic trees as your baseline.
The Translation Projects menu is also planned to receive such updates. Even though you can filter out unimportant translation projects in this menu as described above, translation projects cannot be deleted because of all the changes that starting them involves. As a result, the menu can fill with less relevant items over time because of test attempts, for example. As such, we have planned to include commands in this menu for hiding individual projects and then to filter the view to not show them. They could then be made visible when necessary, though.
Summary
Each menu in DoX CMS can be filtered easily and swiftly to only show the content that is relevant at the time. You need not track content through a tree structure or using a sepatate search function where you have to specify the values for each column at once. The filtering of content updates in real time to track changes made to said content.
Each menu has its set of columns that can be used to filter the view. It is thus important that you decide which columns to use to fit your needs. Such matters ought to also be considered at the level of your organization’s conventions. Column visibility is controlled with the button on the upper left corner of all menus with lists. Content can also be filtered based on what its source XML contains.
The title field of each column holds a seach function which shows when the cursor hovers above it. While this text field has content written or selected, the list in that menu only shows matching items. You may apply several such filters simultaneously. Column title fields also contain buttons that let you change the ordering of the view to either ascending or descending relative to the values of a given column.
Menus often have fields for details like descriptions that can be used to control the view with the help of keywords, for example. Other values such as tags or publishing variables that have their own columns can also be used in such a manner.
The means to control views are still under active development, including the adding of more columns to help find correct content within a menu. We also strive to add other features that help make the correct choices related to content management.