What’s New and Changed in CATMA 7

It will take us some time to update our documentation for CATMA 7. In the mean time, this page provides an overview of what’s new and changed.

Introduction of New Project View Modes

CATMA 7 introduces two different collaborative project view modes:

Synchronized, showing the current state of all work that has been integrated, plus anything that you as an individual user have done on top of that, and …
Latest Contributions, allowing for read-only access to all project members’ latest work — an additive view that combines the current integrated project state with the latest changes, without the need for synchronization or complicated integration and conflict resolution work up front

The default view mode is Synchronized, and the currently active view mode is displayed in the top bar, next to the project name.

In collaborative projects, that is projects with more than one member, the Switch View button is enabled to allow for switching between the view modes. When switching to the Latest Contributions view, the project enters a read-only state and allows you to see what the other members have been up to:

As you can see above, the top bar now indicates that we are in the Latest Contributions view and that the project is read-only. The resources highlighted in blue have been added or modified by another project member.

You can view and interact with the other members’ resources in this view, but as already mentioned, you can’t make any changes. For example, you can view documents that they have uploaded as well as any associated annotations. You can also run queries or view visualizations in the Analyze module.

Note that the blue highlighting is confined to the Project and Tags modules, and is not present in any of the slide-out panels where you select resources in order to limit distractions.

Lastly, don’t confuse the Synchronized view with synchronization itself. When the badge next to the project name indicates “synchronized” it refers only to the currently active view mode. Read more about synchronization below.

Synchronization

Synchronization is not going away, but shouldn’t get in the way as much, and is only needed when you truly want to integrate multiple people’s work in a collaborative project, at a time that you choose.

As you can see in the screenshots above, there is now a button titled Sync. Clicking this button starts the process of integrating your changes with the most recent integrated project state. In other words, it attempts to integrate anything you have done since you last synchronized. This can lead to conflicts (where two or more project members have made conflicting changes), which sometimes have to be resolved manually.

Using Git and GitLab terminology, synchronization creates a Merge Request (a.k.a. Pull Request) to merge your user branch into the main or master branch. Where possible this Merge Request is automatically merged. If an automatic merge is not possible, the Merge Request remains open and can be inspected in our GitLab backend. Previously we always tried to merge completely automatically, but this often led to problems and projects being in a broken state. Users couldn’t resolve such a situation without our help. Now, we are relying more heavily on the automation and tooling that GitLab provides, making it possible for users to take action themselves (the caveat being that we have to expose them to more of the “Git stuff”).

OK, got it. Tell me more about the Git stuff and the relationship between synchronization and the project view modes.

Below you can see the Git graph for the same project that is shown in the screenshots above:

This project has three branches – the main or master branch, and a branch for each of the project members, in this case malte and se3. Reading from the bottom up, the first red dot shows the creation of the project, which is a commit on the master branch.

The green line and dots show commits that were made on the malte branch. After creating some annotations semi-automatically, malte decided that he wanted to integrate his changes with the most recent integrated project state, which at that point was still the first red dot, the point at which the project was created. He clicked the Sync button, a new Merge Request was created and then automatically merged.

Next, se3 joined the project. At this stage, the most recent integrated project state was the point at which malte was merged into master – the current state of master and thus their starting point. se3 did a few things themselves, but they did not click the Sync button. Their line is shown as a continuation of master because nothing else has happened on the master branch yet.

If you now take a look at the screenshots showing the different project view modes again, things should start to fall into place. Both show the project from malte‘s point of view.

In the Synchronized view, he is looking at the current integrated project state (master branch), plus anything he has done on top of that (malte branch). Because he hasn’t done anything new since last clicking Sync, the two branches are at the same point. He can’t see anything se3 did in this view, because those changes haven’t been integrated (merged) yet.

In the Latest Contributions view, he is seeing the same thing as in the Synchronized view, plus anything other project members have done but not yet synchronized (shown in blue).

If se3 now synchronized, the merge process would start over and the integrated project state, that is master, would advance to where se3 is now (assuming a successful merge without conflicts). In this case, it’s important to note that from malte‘s perspective, the integrated project state would not have moved on – not until he clicks Sync again, to once again merge malte and master. In other words, his copy of master would be “behind” where master actually is until he synchronizes. Until then, anything new he does will only be present on the malte branch and will only be visible to others if they switch to the Latest Contributions view.

Simplification of Roles and Permissions

A simplification of the roles and permissions system was unavoidable as part of fixing the performance issues, but the way that it used to work also proved to be too complicated and difficult to understand for our users. Aside from that, the version control functionality that is built in with our GitLab backend means that all changes are recorded and mistakes can be rolled back with relative ease.

The Observer and Student roles have been removed, and it is no longer possible to assign permissions at an individual resource level. That means that permissions are now project-wide and apply to all resources.

We have also introduced the concept of responsibility. While project members can no longer be prevented from seeing or changing each other’s work, they are now warned when attempting to do so:

Each project resource now records the member that is responsible for it (by default this is the person that created the resource). This can be seen in the Project module in the column Responsible:

Known Issues

As with all software releases, we will probably find unexpected problems or bugs after launch. At the moment we know of the following issues:

The responsibility warning (screenshot above) may be displayed when it is not expected. For example, when you are adding a tag to a new tagset that you just created.

Please Contact us if you find anything else!

That’s it for now — we hope you have fun using the new version of CATMA!