Communicate publishing is in progress (original) (raw)
Publishing a translation is an important action that creates the Wikipedia article the user has been working on. We want to communicate clearly the different stages of the process. These are the aspects to support in each one (checkboxes are used to distinguish the aspects already supported from the pending ones):
| Before publishing | During publishing | After publishing |
|---|---|---|
 |
 |
 |
Before publishing
- The "Publish" button is active when there is some content in the translation.
During publishing
- The "Publish" button becomes "Publishing..." and becomes disabled.
- The contents (source and translation) are disabled. Users cannot modify or interact with them. They are shown at 60% opacity to communicate their disabled state.
- As part of the disabled interactions, the "+add translation" placeholder, paragraph/sentence highlight or other hover-based interactions should not be active.
- Disable publish settings while publishing, to make it clear that changes made such as the destination of the article are not considered for the current publication in progress.
- Only the tools that are relevant at the document level are shown, and they are shown as disabled (having no effect on the document).
- The auto-save label ("Saved X minutes ago") is cleared, to avoid sending conflicting messages.
After publishing
Content and tool become active again.
The publish button will become "Publish" again.
If publishing went successful, the publish button will remain disabled until the content is modified again.
If publishing failed or warnings were shown, the publishing button will become enabled, allowing to try to publish again without the need for making further changes.
Communicating the success (T188733) or problems after publishing is part of separate tickets.
Event Timeline
- The contents (source and translation) are disabled. Users cannot modify or interact with them. They are shown at 60% opacity to communicate their disabled state.
I'm moving this to QA so this can be checked. After that, ticket can be returned to Priority backlog/In progress for other work.
Things missing from the above patch:
- Categories count button (above content) and categories list (below content) are still interactive during publishing
- Target title can be manipulated during publishing. We want to disable changes to target title, both manually and via namespace change.
I've updated the ticket description for the specs that are done.
To summarize what needs to be done:
- The auto-save label ("Saved X minutes ago") is cleared, to avoid sending conflicting messages.
- If publishing went successful, the publish button will remain disabled until the content is modified again.
as per @Petar.petkovic comment:
- Categories count button (above content) and categories list (below content) are still interactive during publishing
- Target title can be manipulated during publishing. We want to disable changes to target title, both manually and via namespace change.
Note: The tools are displayed as active (except for Undo and Redo) and they are clickable, but they do not affect the article in the process of being published, so I marked the spec is done.
I let @Etonkovidova to check remaining points in the description after QA process.
as per @Petar.petkovic comment:
- Categories count button (above content) and categories list (below content) are still interactive during publishing
- Target title can be manipulated during publishing. We want to disable changes to target title, both manually and via namespace change.
Although two of these aren't directly stated in description, issues that may arise from their interactivity during publishing are unlikely, but real. First issue is already dealt with, and other (changing target title while publishing) will probably require separate ticket. Problem described in T188484#4056847 is similar and one ticket can encompass both target title editing problems.
Checked cx2-testing for the fix @Petar.petkovic mentioned - works as expected.
Categories count button (above content) and categories list (below content) are still interactive during publishing.
The only issue is still unresolved:
If publishing failed or warnings were shown, the publishing button will become enabled, allowing to try to publish again without the need for making further changes.
So far I saw only three cases of warnings
- (1) "This translation is based on older version..." which does not prevent publishing
- (2) "An error occurred while publishing the translation. Please try to publish the page again. Error: The requested page title contains invalid characters:..."
- (3) "An error occurred while publishing the translation. Please try to publish the page again. Error: error" - when the network connection was interrupted.
In cases like (2) when specific cause of errors is given, there is a little value in 'Publish' button become active immediately after the failure. A user should address the cause and then proceed with publishing.
In cases like (3) it might be beneficial to work on specifying the cause of error in the message.
Btw, btw if the publishing failed, there were no loss of edits,
@Pginer-WMF Should the above spec be part of this ticket? It has not been implemented.
Since T188733: CX2: Confirm translation was published successfully is only about publishing success, I filed T191349: No error messages for unsuccessful publishing with invalid target title.
So far I saw only three cases of warnings
In current state, error handling is poor, which is set to improve after T162768. Although not everything will be handled after that ticket is resolved, especially easiest way to cause fail message to be displayed, which is to use invalid characters in target title. When user types invalid character, that is recognized, but variable which stores target title isn't actually changed. That means when you try publishing after that, you will succeed. Some parts of invalid characters in target title are covered by T190804, but that doesn't cover publishing.
If publishing failed or warnings were shown, the publishing button will become enabled, allowing to try to publish again without the need for making further changes.
I think what is meant to be covered by this ticket is captured in first part of the sentence: enable the button when publish fails. Although, @Pginer-WMF maybe had different idea.
In cases like (2) when specific cause of errors is given, there is a little value in 'Publish' button become active immediately after the failure. A user should address the cause and then proceed with publishing.
There are some mocks showing future framework for displaying warnings and errors - T189488. More information should be provided about the specificity of errors and ideally "Fix this" button will resolve the issue, enabling user to publish without errors. It is up to @Pginer-WMF to decide whether publish button should be immediately enabled after failure, but it may be useful to quickly retry publishing. Some errors may be recoverable, and some may be unrecoverable, where publish button would probably be disabled.
In cases like (3) it might be beneficial to work on specifying the cause of error in the message.
Yes, displaying just the word "error" really look useless, and I hope we will dedicate time to improve that end of error handling as well. There is one ticket to explore common errors with abuse filters (T189475) and we should do the same for other errors, providing better info to the users about what went wrong.
@Pginer-WMF Should the above spec be part of this ticket? It has not been implemented.
Since T188733: CX2: Confirm translation was published successfully is only about publishing success, I filed T191349: No error messages for unsuccessful publishing with invalid target title.
Title of that bug is covered in T162768, but actual description mentions errors with invalid characters while publishing, which should be dealt with separately and your ticket can be used for that. So, title of the ticket may need to be changed.
Communicating errors and warnings is a big topic that we want to deal with separately. I created a ticket capturing the general idea (T189488), as well as specific tickets for each kind of error. Since errors are hard to reproduce, it would be good to have examples to cover more of the different errors that may happen. So feel free to add screenshots of how any of those are surfaced currently.
For this ticket, what I want us to make sure is that in the case of any error, the user does not get to a blocked state. That is, that even if the publishing process fails for whichever reason, the user goes back to a working editing state with the publish button available. This is not happening currently as I tried this in CX2 test servers for the Paneer article. I click on publish and everything got blocked forever, without the possibility to continue editing or retry:
Another distracting aspect is that the content still seems to react to on hover interactions. Showing the "Add translation" placeholder and highlighting paragraphs. It would be preferred those interactions not to happen in the disabled state, in order to avoid showing an invitation for an action we don't allow at that point.
Errors are generally caught, but not processed properly. Some parts are set to improve after T162768.
Since errors are hard to reproduce, it would be good to have examples to cover more of the different errors that may happen.
There is one error which is easy to reproduce, just insert invalid character in target title. But, it's not handled yet, and reason I wrote "some parts" in above sentence. It will be handled separately, probably very soon.
For this ticket, what I want us to make sure is that in the case of any error, the user does not get to a blocked state. That is, that even if the publishing process fails for whichever reason, the user goes back to a working editing state with the publish button available. This is not happening currently as I tried this in CX2 test servers for the Paneer article. I click on publish and everything got blocked forever, without the possibility to continue editing or retry:
What you observed is not publishing error, it's JavaScript error. When you click "Publish", target title is checked for availability. If there is existing page with same title, dialog to "Publish anyway" should be shown. At that point JS throws error, and you're stuck endlessly. This patch deals with that.
Another distracting aspect is that the content still seems to react to on hover interactions. Showing the "Add translation" placeholder and highlighting paragraphs. It would be preferred those interactions not to happen in the disabled state, in order to avoid showing an invitation for an action we don't allow at that point.
Maybe it'd be good to add that as check item in the description.
Thanks for your comments and the work on this, @Petar.petkovic. My replies below:
Errors are generally caught, but not processed properly. Some parts are set to improve after T162768.
Great, looking forward to it.
There is one error which is easy to reproduce, just insert invalid character in target title. But, it's not handled yet, and reason I wrote "some parts" in above sentence. It will be handled separately, probably very soon.
That will be a useful one for testing. I already created a ticket for that specific one (T190804). I'll move it to the priority backlog in case it is useful as an example to work on.
What you observed is not publishing error, it's JavaScript error. When you click "Publish", target title is checked for availability. If there is existing page with same title, dialog to "Publish anyway" should be shown. At that point JS throws error, and you're stuck endlessly. This patch deals with that.
Thanks for identifying the cause and working on a solution. As a more general point, I wonder if this can be coded in a way that is more resistant to such kinds of errors, so even if there is an unknown error (or a regression in the dialog code) happens, the user does not get into a blocked state.
Maybe it'd be good to add that as check item in the description.
I added a specific check mark, the previous remark about "users cannot modify or interact with them" was definitely ambiguous with respect to hover.
Moving back to 'In Progress' for addressing the missing requirement.
- highlighting of paragraph(s) is available during puvlishing
- 'View page' is active
Btw, 'All translation' is disabled, I think.
Moving back to 'In Progress' for addressing the missing requirement.
- highlighting of paragraph(s) is available during puvlishing
- 'View page' is active
Btw, 'All translation' is disabled, I think.
"All translations" button isn't disabled.
@Pginer-WMF, what do we want for "All translatons" and "View page" buttons? Do they need to be disabled during publishing?
"All translations" button isn't disabled.
@Pginer-WMF, what do we want for "All translatons" and "View page" buttons? Do they need to be disabled during publishing?
I'd keep the "All translations" button active, to avoid restricting the freedom of navigation. They can move to the list of translations if they really want to while the translation gets published.
I'd keep the publishing settings disabled while publishing, to make it clear that changes made such as the destination of the article are not considered for the current publication in progress.