Tracking changes with LibreOffice

The Libreoffice UX team shows a proposal for the management of change tracking. It intends to have a comprehensive and good-looking overview but with the flexibility to add future enhancements.

This article was posted first on 2015-Feb-19 at user-prompt.com (site closed now)

Introduction

Track changes is an essential feature that separates word processors from simple text editors. While change tracking is rather a collaboration tool, as it allows multiple users to make revisions without losing the context of the original document, it is widely used in business to get consensus on documents.

Libreoffice Writer provides this feature since the dawn of time. Change tracking according the ODF 1.2 specification involves for instance the option to add/delete/move and edit text. It also includes formatting, but not in case of templates. And when it comes to page infrastructure the competitors track much more information. Currently, there is an ongoing discussion for an updated ODF version.

Figure 1: Change tracking in 4.3

Additionally to the missing functionality the current UI has some room for improvement on the navigation part. Figure 1 shows  how the change tracking is managed currently.

Some issues with the change tracking have been accumulated over the last release cycles and have been collected along with requirements and a competitors’ analysis in the wiki. The Libreoffice UX team discussed the issues over the last weeks and wants to present a proposal which is planned to get integrated into release 4.5.

Requirements

Although we do not have personas for Libreoffice the following user stories are written for the fictive user Martin.

Core functions

• Martin wants to start and stop the change tracking to activate the functionality.
• Martin wants to be able to add comments to changes in order to clarify the reason, for instance.
• Martin wants to accept/reject both individual and multiple changes to deal with revisions.
• Martin wants to protect the changes in the document from being accepted/rejected without permission.

Navigation

• Martin wants to browse through changes in order to find the next/previous item and to get an overview.
• Martin wants to filter the changes to see only those from a particular date, author, type of action, or comment.
• Martin wants to be able to sort changes to prioritize the list by date, page, author, or action.

Future enhancements

• Martin wants to easily identify second level changes (the change of a change) for a threaded review.

Proposal

Basic assumption of the proposal is to have a comprehensive and good-looking implementation but with the flexibility to add future enhancements. The idea is to show the changes in a listbox at the sidebar,  along with a set of toggle buttons on top to sort the list.

If the threaded review comes true (as quoted in the requirements section) the list box can be transformed into a tree view. But some aspects should be taken into consideration then: What happens to the tree on filtering/sorting? or How to deal with threads where parts are accepted/rejected?.

Figure 2: Mockup of the proposal

Adaptive Filter

To filter this view we want to introduce an adaptive filter. This pattern consists of a dropdown with the type of filtering (author, date/time, page etc.), the kind of relation that depends on the type (“between” makes only sense for time, “is not” would be appropriate for author, “above” or “below” is useful for pages, and so on), and the effective values which depends on the previous settings as well. You can AND-combine multiple filters per click on the plus button right hand. In case the controls do not fit into the limited space on the sidebar the filter settings need to go into a separate dialog. The combobox above the list, which can be used to store the current settings, would still be available by default. The filter in combination with the Show (tracking) option at the toolbar above allows to hide all filtered items in the document.

Since most users might not benefit from the filter option the checkbox that enables the filtering may hide all controls.

Interactions

The most important controls should be placed in the sidebar to support the workflow. At the top we provide access to Start (actually it toggle tracking on/off), add change Comment (enabled only when tracking is active), and Show changes. All three buttons can be toggled on or off. Functions that relate to the list of changes are located below. That is Previous/Next and Accept/Reject. The latter applies to the current selection (therefore it makes „accept all“ superfluous). As usual you may select multiple items by using ctrl and shift. And in order to support accessibility a context menu offers some options for selection too.

Of course, the familiar workflow would be still available. Removal of the changes toolbar is not a matter of discussion therefore.

Visualization

Since change comments are very similar to normal comments (ctrl+alt+C) it should be shown in the same way. And that is within the document. We suggest to indicate the change comment by using a different position and place it left to the paragraph, as defined by default for the markers. Both types of comments may come from different users and get colored respectively.

Discussion

Change tracking is an essential feature of Libreoffice. Based on users’ requirements we presented a mockup in figure 2 with a solution for most problems. First steps for implementation in 4.5 have been done. But we want to make sure that development is being done user centric. “Close, but no cigar” is not an option.

So what do you think? Would you benefit from a threaded review? Please let us know if we missed one of your use case or in case you have something to add.