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.

@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.

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.

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.

@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

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.

@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

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.

We've updated the design based on the discussion above. You can find the link to the Figma file here:
Bulk Publish Step 1 flow

However, we noticed that the transition between the completeness check and the IATI validator is not clear enough for users to understand the process. To address this, we propose dividing the steps into three stages to give users a clearer view of what is happening. You can see the updated design below.

Initially, we aimed to reduce the number of clicks by simplifying the steps, but we believe this change won't increase the number of clicks. If there are no issues during any of the steps, the process will proceed smoothly without requiring additional user actions.
Bulk Publish Step 1 flow - revision

Hi @shreyaydi - the Figma designs aren't loading for me for some reason. Based on what Bibha & Momik demoed on today's call, the updated design looked logical in terms of detecting when activity data has changed and prompting the user to refresh.

I am happy to change to the three-step revised publishing progress bar provided this a) does not introduce unnecessary user action or clicks (as you've said) and b) the steps are kept simply labelled - e.g. "1. checking", "2. validating", "3. publishing".

Part of the reason for moving to two steps was to remove the amount of complexity we were showing to the end user about the checking that was taking place, as well as reduce user action needed to get through the process.

Can you give a rough estimate of how many days effort will be needed to implement this to help plan this month?

A point to add - after discussing with my team this week, we think it is making more and more sense to prevent users from publishing activities with critical errors.

This is because it takes up a lot of time contacting users about fixing errors after they have published and many users are not responsive. Activity data with a critical error (as defined by the IATI Validator) will not be processed by many IATI tools so there doesn't seem to be any benefit of IATI Publisher allowing it. Let me know any reasons otherwise.

Am I best raising a new issue for this, or is it easier to combine with this work on the publishing process? I'm trying to save us having to redo any work.

@emmajclegg I won't be available on IATI Publisher until November 18. I haven’t had the chance to review the required changes yet or determine whether it would be easier to implement them now or address them in a separate issue. I’ll leave a comment once I have a clearer understanding. In the meantime, @Yash-ftW will continue working on the changes suggested in the design.

Ok, no problem @PG-Momik. Any questions @Yash-ftW, just let me know.

Thanks for the estimate and breakdown of steps for this @BibhaT.

I can view the latest Figma designs now, which is helpful @shreyaydi. Apologies for a bit of back and forth on this but it's a complicated workflow to think through and I'm keen we get it right on this second release. Can I suggest a compromise between the original and latest designs?

1. We show the core element completeness check as a warning, rather than a list, as you suggested previously:
   
   This simplifies things in hindsight. I think core completeness is best kept as a %, however, and we probably want to avoid use of warning signs (!) against activities in the activities list as I would associate these with data errors. From memory, information on deprecated codes is displayed elsewhere to users in the activity detail pages, so I don't think it's essential we highlight deprecated codes during publishing.

2. We then move to the publishing progress box for the two most important steps (1 - Validating, 2 - Publishing)
   

3. Users can exit to edit activities based on the validation feedback, return to the publishing process, and be prompted to revalidate if needed:
   

As currently is the case, if there are no core completeness or data validation problems, the workflow would proceed straight to publishing without any user action needed.

My reasoning:

• The core completeness check becomes a "softer" warning here, which focuses user attention on the more important data validation check. We want to strongly discourage users from publishing activities with errors, whereas core completeness is more of a recommendation.
• Under this revised approach, IATI Publisher only has to detect changes to activities once during the publishing process, not twice
• Preventing users from publishing activities with critical errors in future (as I've mentioned above) would make more sense in this simpler workflow, where it is easy for a user to see and edit an activity that has errors.

What do you think? Any questions, let me know.

• Issue 1 : Sometimes while publishing the activity it gets stop at the publishing activities section. Please have a look on it.
  
  

• Issue 2: The user is able to select the activity that contains critical error and publish it although an error message gets displayed on it.
  Steps to reproduce :

1. Click on the publish activity that contain critical error.
2. After getting Critical Error copy the link.
   
3. Paste the link in the new tab .
   

Expected Result : The activity that contain critical error should not be selectable.
Actual Result : The activity is selected and user can click on continue publishing.

• Issue 3:
  a. The following error message is displayed when the user cancel the activity publication while switching from validation to publication. (Refer Video)
  
  b. The minimize box gets disappear automatically. (Refer Video)
  Refer Video.webm

• Issue 4 :
  The 0 Issue found is displayed in the top error box of the 100 PERCENTAGE completed activity while it should not display the error box.
  

• Issue 5: The error message should display indicating that the activity is already published when the user try to publish the activity that is already published . Refer Video for it. -- will handle later
  Video.webm

• Issue 6: When the user cancel the checking publication process while publishing the activity then the process should get cancelled but they move to the next box. (Refer Video)
  
  Untitled_ Jan 15,2025 11_31 AM (1).webm

@Sanam-07 Crossing out Issue 3. Cancel API completes faster than the initial checks in start publish API. Cancel API removes import status form import_status table in the db. Causing start-publish API to return a falsy value on the critical error check ( this check relies on import status table and is not flexible since we need to query into json).
Scenario for Issue 3 has been marked as not realistic since, users are not likely to cancel publish right after validation is complete, but right before the publish actually starts.

Will need time to solve. Will get back into it when possible.

cc: @BibhaT

Hi @emmajclegg, This has been deployed to staging.

When publishing a single activity or group of activities with non-critical errors, the publishing progress bar automatically moves to step 2 ("Publish") without giving the user feedback that there may be data quality issues. I don't think this was an intentional change? It doesn't happen when publishing an activity with non-critical errors alongside one with critical errors.

Yes this is an intentional change, Also there might be an issue with position of the support button when clicking the minimize button. I've done a quick fix to fix the position of it but it might raise an issue later. In order to solve it, we have to give more time to it as we need to look in a deeper context.

@emmajclegg This has been deployed to staging. As mentioned in the previous call Issue 3 reported by @Sanam-07 has been flagged as low priority/not realistic.
Steps to recreate issue:

1. Create multiple activities with no errors. (no critical errors, no errors, no warnings).
2. Bulk publish them.
3. Immediately when the progress bar moves from Validating... to Publish, press cancel.
4. when cancel is pressed, if a popup model containing the text "All of the selected activities have critical error" is seen, the issue is recreated.
5. There might be cases when the mentioned issue might not appear as well.

Ok thanks @PG-Momik - I'll carry on looking at this tomorrow and give feedback

Thanks for the work on this all - it's looking better. Some feedback:

1. Activities with non-critical errors - we want users to be warned about data quality issues for these, as currently happens after Step 1 validation, and the process not automatically continue to Step 2 (publishing the activities).

It's inconsistent at the moment that feedback is given on these activities if they are published alongside a critical activity, but not if there's no critical activity in the bulk publish.

i.e. this screen should appear in all cases of activities with non-critical errors:

2. Prompting re-validation if activity data has changed - can we remove the option to "Continue to Publish" here and force the user to "Revalidate"? As mentioned in my last feedback, if we don't do this, the validator errors shown on the activity detail page (once the user has published) will not be accurate.

3. Minor changes to interface text:

It's no longer true that the user can always continue to publish from the screen below. I suggest simplifying the message to "There may be data quality issues with these activities", or making sure the activity count is accurate.

"Thus" is also not needed in the "activity contains critical errors" message.

On YI's other points....

Also there might be an issue with position of the support button when clicking the minimize button. I've done a quick fix to fix the position of it but it might raise an issue later. In order to solve it, we have to give more time to it as we need to look in a deeper context.

@Yash-ftW - I suggest I raise a separate issue about the Support button positioning, as we've also noticed it overlaps other buttons at certain screen resolutions. It's something we can look at at a later date.

Thanks, and any questions let me know!

Hi @emmajclegg,

Prompting re-validation if activity data has changed - can we remove the option to "Continue to Publish" here and force the user to "Revalidate"? As mentioned in my last feedback, if we don't do this, the validator errors shown on the activity detail page (once the user has published) will not be accurate.

The text here needs updating. Could you please let me know what text should be written here?

@emmajclegg, This has been deployed to staging. Please let me know if everything's working fine.

P.S: Awaiting your response for the text changes.

Thanks @Yash-ftW

For the text below, I suggest a single line would be sufficient: "Changes have been detected in your activity data. Please revalidate before continuing."

I've tested publishing activities with different kinds of errors and the publishing process behaviour is as expected, which is great.

Last observations:

1. In the scenario of publishing an activity without errors alongside activities with errors, it's not super clear to the user at the moment that the activity without errors requires no action.

Activity 1 in the screenshot below has no validator errors, as an example. Is it possible to remove the "Open in new tab" link for activities like this, as the user doesn't have to edit the activity?

Also, now that I've seen this scenario, I recommend changing the header wording to: "Activities marked with this symbol have data quality issues"

2. I've noticed that the "refresh to see changes" message usually appears after I've published an activity, but not always. To check - is there a reason why IATI Publisher can't refresh the activity list automatically without user action here?

Hi @emmajclegg, This has been deployed to staging.

To check - is there a reason why IATI Publisher can't refresh the activity list automatically without user action here?

The activity list was not automatically refreshed during the bulk publishing process, as the user could be on any page when the publishing stage was completed. To address this, functionality has been added to refresh the page when the user clicks the "Close" button after the publishing process is completed in the modal.

Additionally, the toast message remains visible because the modal may be minimized, and a refresh is required to ensure changes are reflected for the user.