Version 4.9.3.0 is a release dedicated to PDF features. We have added an embedded PDF viewer to the Web application and made PDF coding (also known as "inductive coding") available therein. Importantly, we have put considerable efforts into making sure that PDF coding done in either version (Silverlight or Web) will be available on the other, and, whenever possible, fully functional, irrespective of where it was first created.

New features

EPPI-Reviewer Web can now display PDFs in the full UI, the Coding UI will receive this functionality later on. To make this possible, we are using a well-known technology: PDFTron. This underlying component also allows to load, generate and save the "highlights" used to signpost coded text. However, the way used to represent coding highlights in the two EPPI-Reviewer interfaces is not exactly the same, which requires both systems to do extra work in order to deal with highlights generated in the other interface.

This two-way, real-time conversion is always possible in terms of showing all highlights, no matter where they were created, but can introduce some limitations in terms of editing existing highlights.

PDF Coding in EPPI-Reviewer Web

To make sure the system works and offers a good user experience in traditional desktop systems as well as touch devices, the PDF Coding feature allows to create new highlights as well as display and delete existing ones. Unlike in EPPI-Reviewer 4 (Silverlight), to edit an existing highlight, users will need to remove the existing one and re select text as needed. Codes are added to text in a way that reflects how it is done in the Silverlight version: users need to select a code on the tree on the left (they don't need to tick the checkbox, just clicking on the code name will do). The currently active code name is shown on the top toolbar above the PDF contents. To apply the code to some text, users need to select the code. When some text is selected a small dialog will appear near near the selection, offering two actions: "Copy" and "Highlight", picking the second will assign the text to the current code and show the corresponding highlight. Like the Silverlight question, changing the currently selected code will load the highlights present for the current "document" and "code" combination, if any.

When loading coding highlights generated on the Silverlight version, the system will "digest" them in order to reconstruct their representation in its own "native" format. When the operation succeeds, the highlights will be fully compatible with EPPI-Reviewer Web and work in exactly the same way as highlights generated in it. Otherwise, they will be displayed with a darker shade: these highlights will typically "group together" larger chunks of (not necessarily continuous) text, but would otherwise behave like fully-recognised highlights.

Please note that the "digestion" phase could last more than 10 seconds, when a PDF contains large amounts of coded text created in the Silverlight UI (for the current code). However, once the digestion is done, the result is immediately saved, making sure the "digestion" delay will happen only once (for a given document and the specific code).

Changes to PDF Coding in EPPI-Reviewer 4 (Silverlight)

To make both systems mutually compatible, also the Silverlight version was updated, adding the capability of displaying and handling highlights generated on the Web interface. When the Silverlight UI receives some PDF coding created on the Web version, it will try to "digest" it (in this case, without noticeable delays) - on a per-code, per page basis. If the "digestion" works, highlights will be shown and will work exactly as before. If the digestion does not work, the highlights will be shown, but for the page affected, they will not be editable in the normal way. Trying to edit such a "partially digested" highlight will show a warning, saying that the selection in question can't be edited, and offering the chance to remove the coding for the entire affected page and start again (only impacts the currently active code).

Usability considerations

Each time highlights generated on one version get edited on the other, the original representation of the highlights (in the current page) will be replaced by the native description of the version where the editing happened. Thus, moving back to the other version of EPPI-Reviewer and loading the edited data will incur in the reverse "digestion" cost, with the possibility that the digestion will not be complete (see above). As a result, we believe that teams engaged in large PDF Coding exercises (especially if they expect to edit/refine the coding them multiple times) should probably agree what version they will use and do all their PDF coding and (collectively) stick to it, whenever possible. Two-way compatibility should work, but might entail a few, otherwise unnecessary, small inconveniences.

Bug Fix

In the Web-version, Item Details page, very long URL values for the current reference would force the page to become wider than the containing window. This meant that users had to scroll horizontally, in order to see all the reference details. This problem is now fixed: in such cases, the URL field will not "overflow" and display its own scrollbar if/when needed.