Check expected behaviour of publishing progress box when exiting to view data quality issues

[emmajclegg]

Under the new publishing workflow released (#1423 ), can I check varying behaviour when the user views an activity to troubleshoot missing core elements or data quality errors.

Case 1 - I see that an activity is missing core element data

Action: I click the arrow highlighted red below to go to the activity:

Result: I see the activity in a new browser window WITHOUT the publishing progress box on screen:

I add data to it if I want, then close the browser window and return to the previous publishing progress window.

Case 2 - I see that an activity may have data quality issues

Action: I click the arrow below to go to the activity:

Result: I see the activity in a new tab WITH the publishing progress box still on screen:

I don't think this Case 2 is expected behaviour? The user has to cancel the publishing process in this case, then figure out where the data quality errors are (issues are displayed in top right). It would be more intuitive to show the individual activity page without the publishing box, as in case 1

[shreyaydi]

Approach 1 - we ask the user to reload individual activities to update the changes.

Approach 2 - We increase user awareness of their publishing progress, reducing the potential for confusion.

[emmajclegg]

@shreyaydi

Approach 1 - we wouldn't trust the user to click "refresh to update" in this design, unless IATI Publisher prompts them to do it (i.e. the tool detects that a user has changed an activity since the publishing process was started). @robredpath suggested performing that check as the user clicks "continue publishing anyway" - can you remind me what the problem with this was?

Regardless - it's not worth a week's worth of work to implement Approach 1 here. The better quick fix would be to cancel the publishing process completely once the user clicks to view and edit a particular activity - how much work would this be to implement? I know this isn't ideal, but it's better than the user thinking they've published updated data when they haven't.

Approach 2 - this still forces the user to exit the publishing process to make changes to an individual activity - is that right? (I see that it's less likely the user would try to exit and change activity data under this design, but that may be counterproductive for data quality). I'm not convinced this is a better long-term workflow in summary.

[Yash-ftW]

Hi @emmajclegg , Okay. We'll proceed with the original bug fix of closing the popup on the newly opened tab. Do note that if the user clicks on publish anyway on the previous tab (after they have made changes in the new tab) the changes will not reflect. Please let me know if you have any questions.

[emmajclegg]

Do note that if the user clicks on publish anyway on the previous tab (after they have made changes in the new tab) the changes will not reflect.

Hi @Yash-ftW - when I originally raised this issue, I wasn't aware of the point above so I no longer think what I was suggesting is sufficient to stop the user inadvertently publishing out of date data.

Approach 1 - we wouldn't trust the user to click "refresh to update" in this design, unless IATI Publisher prompts them to do it (i.e. the tool detects that a user has changed an activity since the publishing process was started). @robredpath suggested performing that check as the user clicks "continue publishing anyway" - can you remind me what the problem with this was?

Is there no way under approach 1 that IATI Publisher can detect changed activity data and force a refresh (or prompt the user to refresh)? We like the current two step publishing progress box as it guides users visually through the publishing steps, so would be hesitant to lose that under the approach 2 design.

[PG-Momik]

@emmajclegg I think our main focus should be on whether users can be trusted to accurately resolve validation issues. Although we could implement a backend mechanism to detect changes in data, it doesn’t guarantee that validation issues have actually been addressed. There's always a risk that users might unintentionally degrade the data. If we allow users to publish based solely on a signal that activity data has changed, we introduce two problems:

• The validation issues displayed on the activity detail page would reflect the data state before any updates.
• Users would be unable to revalidate unless they republish the activity.

Thus, we should focus on revalidating the modified activity date. (Which is why we suggested refresh buttons in approach 1)

Is there no way under approach 1 that IATI Publisher can detect changed activity data and force a refresh (or prompt the user to refresh) ?

The team discussed methods for detecting changes, but there's no viable way to perform a seamless detect change -> revalidate ->update list . At least one intervention is needed. It would be counter-intuitive to convey the message to the users via texts instead of action.

We like the current two-step publishing progress box, as it visually guides users through the publishing steps.

Considering these points, here’s a proposed flow that keeps the current workflow intact:

Summary

• Steps till seeing list of activities with validation issues remain same.
• If a user chooses to fix activity data by opening in new tab, we maintain a list of changed activity in backend.
• When user clicks on Publish anyway, on the backend before actually publishing the data, we check if any activity has changed by looking at the list we maintained.
• If no activity have been changed, we publish the dataset.
• If any activity has/have been changed, we return an API response that allows the frontend to prompt users to revalidate those activities.

cc: @BibhaT @Yash-ftW @shreyaydi

[emmajclegg]

Thanks @PG-Momik - that revised workflow makes sense to me.

To check - we currently let the user exit to edit an activity after the core element completeness check too:

If a user has made changes here (e.g. if they have opened a new window to add a missing core element to an activity, then returned to the publishing process), will that also trigger the "has activity data been changed? = YES" part of your workflow?

If not, we should probably review whether to let users open activities in a new window at that step or not.

[PG-Momik]

@emmajclegg

If a user has made changes here (e.g. if they have opened a new window to add a missing core element to an activity, then returned to the publishing process), will that also trigger the "has activity data been changed? = YES" part of your workflow?

It was not part of the workflow I suggested, but can be done. The mechanism to detect changes after validation and displaying the prompt is similar, so same workflow can be implemented for core elements completion modal as well.

If that works for you, let us know, and we can have @shreyaydi start on a design mockup.

cc: @BibhaT @Yash-ftW

[emmajclegg]

Yes that works @PG-Momik. I'm happy for @shreyaydi to start on design work, then let me know an idea of implementation time & effort when you know.