We are running 3.2.0.3. We recently discovered that, for reasons we still cannot identify, the Crossref DOI generation pattern in the “Crossref XML” plugin for one of our journals had been changed from the standard format to a custom one that was not desired. In our efforts to remediate this, we found a few places where a change of terminology or more dynamic updating of statuses in the plugin could have helped, and we wanted to draw them to attention.
-
After changing the selected pattern and hitting “Reassign DOIs”, the plugin displayed the new DOIs next to each article but large numbers of entries retained their “Active” status. We presume this is because those articles still had active and properly resolving (old) DOIs, but of course those DOIs were not the new ones just assigned. The message was thus misleading, since the DOI shown was not, in fact, active. It would be helpful if that status would update specifically to reflect the fact that the newly assigned DOIs have not yet been deposited.
-
When the newly-assigned DOIs are deposited, their status as duplicate DOIs triggers a generic error message and marks the deposits as “Failed”. This is misleading, however, as the deposits have actually been successful and are correctly resolving; they are simply duplicates (as the user can learn if they click on the “Failed” status). It would be helpful to give the user a more specific original message and/or to provide a separate “Duplicate” status that can be shown on the article list to distinguish these from DOIs that have failed to deposit.
-
To improve efficiency in redepositing, we set the article list to display 100 items at a time, checked the articles, and clicked “Deposit”. Two issues became apparent. First, the user could be spared much unnecessary clicking though the addition of a “Select All” box. Second, the plugin repeatedly failed to process all selected articles, but without giving any error message to that effect. This was further obscured by the plugin’s continual reversion to a 25-item list setting after clicking “Deposit”. It would routinely happen that I would select all one hundred articles, click “Deposit”, and then be shown twenty-five articles marked either “Failed” or “Active” (depending on whether they involved a duplicate DOI), but when moving to the next page of results or setting the list back to 100-item display, I would find, among other “Active” statuses, large numbers of articles still reading “Not Deposited”. It would then be necessary to recheck these, click the “Deposit” button again, and once again identify unprocessed selections, often through three or four cycles before all articles were actually deposited. If there is a limit to how many checked articles can simultaneously be deposited, this needs to be more clearly indicated to the user.
In sum, we are very grateful for the Crossref XML plugin and use it regularly with excellent results. In this specific case, however, where it was necessary to reassign large numbers of DOIs, some of the display elements contributed to misunderstandings on our part that delayed our response to resolution failures of the new DOIs. A couple of (hopefully) small adjustments could, we think, make the process clearer for future users and prevent confusion.