Version 4.4.0.0 is classified as a major release.

This release contains an important (and we hope very useful) new feature, and represents the cornerstone of our latest efforts. In the last semesters, most of our additions were aimed at making improvements in usage efficiency, these included the introduction of code-set types (useful to guide users as well as necessary for the following developments), a new "screening-specific" way of identifying disagreements and now a brand new, hopefully much faster, way of reconciling disagreements. This new "reconcile" function is aimed at "double/triple" coding reconciliations for relatively simple code-tree structures, we are planning to add another brand new feature to help reconciling disagreements when the relevant code-tree is very complex.
In our effort of making your work simpler, we have also renamed the "code-set" data entry modes, hoping to make the meaning of such modes more self-explanatory, this is a cosmetic change (has no effect on functionality), but it is nevertheless important as it should prevent what seemed to be the main source of confusion for new users. Old users should have no difficulty in acknowledging the change in naming convention, full details are below.

Major new functionality: coding reconciliations

There is a brand new "Reconciliation" facility available. It is designed to be primarily used to speed up reconciling double/triple coding applied to relatively simple code-sets (most likely: screening code-sets). We are planning to also write an additional solution for reconciling disagreements when the code-set used is more complex (typically a data-extraction scenario).
To access the feature, in the "Collaborate" tab, click on "View" (stats); for each pairwise comparison, there will be a new "Reconcile" button available.
Clicking the button opens up a new window "Comparison Reconciliation".
The new window will be separated in two: in the top part, the list of all "disagreements" identified in the current pairwise comparison is shown, along with the codes added by each Reviewer included in the comparison.
Clicking on a row will load the document details (title, Authors, Journal, abstract and PDFs) in the bottom part of the screen (resizable), the list of documents is also loaded on the main "Documents" tab, and is paged in the same way, allowing to swap between screens if necessary.
The coding table shows a column for each reviewer included in the comparison, in each cell corresponding to a given reviewer all the codes applied by that person will show up. Clicking on a code will "expand it" so to show the full path of the code within the tree, and the contents of the "Info box" (if any). If the current item coding is not completed a "Complete" button will also be present, allowing for quick reconciliation: users will be able to see the coding decisions made by multiple reviewers, compare them in view of the document details (lower half of the screen), click "complete" for the chosen agreed version and proceed to the next item; this is supposed to be possible via a minimal amount of clicks and without having to leave the current screen, something that we hope will be much faster than the current systems (requires to proceed on a "one document at the time" basis).

In case no already-coded version is correct, each row also contains a link (via the Item IDs shown in the second column) that will close the current screen and open up the old "Document details" window, this will allow to quickly reconcile also the items that need their coding tweaked.
When the coding for a given item has been marked as completed (agreed), the item will appear in green, and the cell of the Reviewer under whose name the coding was completed will show the little green "v" icon that marks completed coding.
Completed items will show an "uncomplete" button to allow users to undo current completions.
In case the completed version belongs to a user that is not included in the current comparison, the current window will not show who completed the coding or what codes were applied; when in doubt, users should click the "ID link" (above) to open up the document details and inspect the coding record (as it was done before).

This window also includes a (help) "?" button that provides succinct information on how to use the reconciliation feature.
Also provided: an "Export" (Save) button. Clicking the button will open a dialog that allows to apply a few exporting customisations: these are
- "Show full code path" (defaults to "no"),
- "Show additional text (info box)" (defaults to "yes"),
- "Show short tile" (defaults to "yes"),
- "Show full title" (defaults to "no") and
- "Show abstract" (defaults to "no").
The export facility is designed to allow saving the full report on the differences in coding (encompasses all levels of the code-tree) and can be used to summarise all differences in coding between the reviewers included in the comparison. The report will show up in the "reports" window and can be saved as a Word file, it includes the "stats" numbers for the current comparison; the table that follows closely resembles the structure of the table shown in the "Comparison Reconciliation" window.

Important Change: Naming convention

The way we call the "data entry" mode of code-sets has changed, what used to be "Multiple User" data entry mode is now called "Comparison"; the "Single user" data entry mode is now called "Normal". This tries to better reflect the purpose of data entry modes: the "Comparison" mode should only be used when planning to do a double/multiple coding exercise, this will always require to compare the coding decision of two or more reviewers, hence the "Comparison" new name. On the other hand the old "single user" designation of what we now call "Normal" data entry mode was objectively misleading: code-trees set in "Normal" mode are not expected to receive coding from one user only; they are "Normal", in the sense that they would not contain multiple (and private) coding versions for each reviewer. A "Normal" mode code-set does not give importance to who added some coding.

Also in this release

Bug fix: copy and paste would sometimes refuse to work, and would display an error message saying that the resulting tree would grow too deep, even if that wasn't the case. This only happened when copying relatively complex branches and is now fixed.

Bug fix: it was possible to create new "randomly allocated" codes within "screening" code-sets and also create the new codes too deep into a code-tree structure. This is now fixed: the "Create codes below this code / set" dialog now doesn't permit to select or expand "screening" code-sets and would not allow the selection of a code that is too deep inside a code-tree.