Optional DOI feature

[sakshamarora1]

Description

Currently, the UI widget by default prompts for an existing DOI. We need to configure it to be optional and not required by default.

UI solutions

Option 1:
We change the text for the button to be descriptive.

Important

If the user selects No (which is already the default in this case) and doesn't click the button, the DOI won't be registered for the record.

Option 2:
We update the UI widget to display 3 options for the 3 cases:

1. User already has a DOI
2. User requires a new DOI
3. User doesn't want a DOI at all. (Default)

Important clarifications

• How to configure this?
  By default it is a required field when DATACITE_ENABLED is set to True. It can be made optional by adding the following lines to the invenio.cfg file:

from invenio_rdm_records.config import RDM_PERSISTENT_IDENTIFIERS, RDM_PARENT_PERSISTENT_IDENTIFIERS
RDM_PERSISTENT_IDENTIFIERS["doi"]["required"] = False
RDM_PARENT_PERSISTENT_IDENTIFIERS["doi"]["required"] = False

(This is already there in the backend, but needs a bug-fix on the deposit form UI to not show the red asterisk in this case.)

• Can it be kept it as it is now?
  Yes, it will be as it is if not configured.

• Editing later
  If the record was published without a DOI, a DOI can be registered later on edit.
  If the record was published with a DOI, it can't be removed later.

[tmorrell]

If there is development resources to do option 2, I think these should be requirements:

• The appearance the "No, I don't require" radio button should be dependent on "required=False"
• Make the selection of what radio button is default configurable. We'd want one repository to default to "Yes" and one to default to "No, I need one". This configuration should be separate from "required=False".

Other thoughts:

• There will need to be backend changes to save the state "No, I don't require". Maybe pids:{doi: {provider: None?
• For option 2, we can stick with the "Get a DOI now!" because clicking the button isn't required.
• I think there should still be a red asterisk for the question, because users have to select one of the radio buttons.
• Another idea for the labels: "Yes, I already have one" and "No, I don't need one"

[ntarocco]

Just to clarify the requirements:

• radio button labels will be adjusted accordingly

• the required:true config flag will show 2 radio button. required:false will show the 3rd one

• when the user selects No, I need one, the user must click on the btn Get a DOI now. Otherwise the validation will fail.

• the default selected radio button will be configurable via the same config. This will pre-select the radio button until the first Save (until the draft is created). When the draft is created, after the first draft, the presence or absence of the DOI will drive the selection of the radio buttons:

  1. if manually input by the user, then the Yes radio button is selected
  2. if the user clicked on Get DOI and obtained it, then the No, I need one is selected with the current DOI shown
  3. if the DOI is completely missing, the No, I don't need one radio button will be selected

The user can change the selection any time before publishing.

If no DOI, the user might come back and edit a published record to obtain/input a DOI. However, the user cannot remove a previosly registered DOI when publishing.

[tmorrell]

I think we should consider the following use case for a repository with required:false

User creates a draft, selects "No, I need one", doesn't click the "Get a DOI now" button, and saves draft. When they return to the draft later the "No, I don't need one" radio button will be selected.

This seems like an odd behavior choice. If the user explicitly indicated they want a DOI, that preference should be saved. If we don't want to save the state explicitly, then maybe it would be better to remove the "Get a DOI" button entirely.

[ntarocco]

User creates a draft, selects "No, I need one", doesn't click the "Get a DOI now" button, and saves draft. When they return to the draft later the "No, I don't need one" radio button will be selected.

The quick workaround to this is that what was proposed above: have a client side only validation that when the No, I need one is selected, the DOI value is required (meaning clicking the button).
Do you think that it is a bad choice?
While I am not a fan of client-side validation only, in this case it might be more beneficial than harmful: sending/saving the state in the record would be needed only for this validation.
Unless... we are missing a corner case.

[tmorrell]

If the "Get DOI button" is automatically clicked when the user clicks "Save Draft", that would work.

But if it's just going to put up a validation error...users are going to be confused. Does the rest of the record get saved? Why do they even need to click the button?

[ntarocco]

If the "Get DOI button" is automatically clicked when the user clicks "Save Draft", that would work.

I see your point. That won't be easy.
I was imaging a clear error msg similar to what you see here:

We will think about this...

[ntarocco]

Reporting feedback here from our last call: the community is more in favour of Option 2.

[ghost]

I'm also in favour of Option 2 and I have the following comments:

@tmorrell said

Make the selection of what radio button is default configurable. We'd want one repository to default to "Yes" and one to default to "No, I need one". This configuration should be separate from "required=False".

• I would even go one step further: Make the selection of what radio button is default configurable:
  • No button is default
  • one of the three options is default
• In this case you can force the user to really make the choice by not giving a default.
• Using a default makes it possible that a user oversees their chance for a choice

@ntarocco said

When the draft is created, after the first draft, the presence or absence of the DOI will drive the selection of the radio buttons:

• in the line with @tmorrell I want to add the following case:

  • the default in our instance is "No, I need one" / (instead of @tmorrell s user clicks that)
  • the user fills the record and saves it
  • with the current idea the default for our instance "No, I need one" would be gone
  • if we decide in our instance for the default "No, I need one" then I would expect, that the user doesn't need to click anything anywhere to really really get a DOI

• the "Get a DOI now" button so far was a strange thing for us anyway:

  • Lars mentioned once, that the use case of this button is the following: the user needs the DOI before publishing the record (for example to add the DOI within the uploaded sources of the record)
  • in our setup we are mostly irritated by this button:
    • First I click the radio-button where I tell the system "I need a DOI"
    • then I need to click a second button to tell the system "I REALLY need a DOI" (aka "Get a DOI now")
    • in an ideal world I would expect that my first request "I need a DOI" is sufficient
  • I know that all this comes from a technical problem, but from a UI view this is irritating
  • maybe it would make sense to do the following:
    • If "I need a DOI" is selected, after the first save the DOI is by default available in the record-draft. The button "Get a DOI now" could go away. Either people learn anyway that the DOI will be available after the first save, or we could add a text with "the DOI will be available after saving this record for the first time" ...

[ntarocco]

Thanks for the feedback!

No button is default

Even if technically possible, I think that this is quite against radio buttons behaviour: one should be always checked, even at the beginning. Otherwise, other UI components should be used (e.g. a button)

in an ideal world I would expect that my first request "I need a DOI" is sufficient

Understood, we will explore this. By the way, in the current RDM, you don't have to click it: if not clicked, a DOI will be automatically reserved and registered.

Thanks for your last suggestion ;)

[ghost]

@ntarocco
you are so right wrt the radio-button without default: it is a pretty bad idea (but seen too often) - once you decided for one option you can never undo your decision and "not check anything". Maybe what we would need/want is a Dropdown-Menu instead.

[ntarocco]

Small update: after a considerable amount of effort invested on this, we had to fallback to the implementation with the extra Reserve DOI Now button.
Technically, it was too complex otherwise. We will demo it at the next telecon.
If someone in the future wants to invest more time on this, we can try to improve it as described here.