FYI changing the auto-dismiss seconds count to 4 as per Codex guidelines.

Change #1016294 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/CommunityConfiguration@master] Editor: Show EditorMessages

https://gerrit.wikimedia.org/r/1016294

@Sgs , is there a way in Codex, to put a backdrop/overlay on the success message that I can use as shown in the figma design?

In T359928#9679545, @Cyndymediawiksim wrote:

@Sgs , is there a way in Codex, to put a backdrop/overlay on the success message that I can use as shown in the figma design?

I don't think we need to add the overlay based on the design discussion in slack thread. There are some issues outstanding that I'm not sure how to resolve.

1. 1. We are not displaying any useful information to the user about where the error is coming from and what to do to fix it. For instance we would show the same message for an offline user and for a user that does not have permissions to write in the configuration. Should we display this information? cc @Martin, and if so, how should we display it? cc @JFernandez-WMF.
   2. Aside from displaying some error details for some errors, I think we should configure the error handling in the editor application to take in account the "debug" flag and display more information about the error when present.
2. How should we deal with long forms? In slack thread, Derek suggests to place the error at the end of the form rather than the beginning. While that helps a bit I find it a bit counterintuitive as a pattern, most MW forms seem to use the "top" for displaying this kind of information
3. If the error is a validation error, the nice UX would include higlighting and maybe scrolling to the appropriate failing field. What do you think? @JFernandez-WMF

Except for (1.A) I think the rest of issues can be handled as follow-ups.

Change #1016294 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: display success and error messages when submitting the form

https://gerrit.wikimedia.org/r/1016294

Checked in eswiki beta - the following notes are for @JFernandez-WMF review :

(1) The success message in Figma designs: "Your changes were successfully saved."
In eswiki beta

• The success message doesn't have a word successfully and the dot is not present at the end of the message. I didn't find references on whether the message has been changed from the original design.
• The success message is not an overlay

Figma - success message	eswiki beta

(2) The error message in Figma designs: "Something went wrong while saving your changes. Please try again later. If the problem persists consider filing an issue in the Phabricator."
In eswiki beta

• "filing an issue in the Phabricator." is changed to "filing an issue in the bug reporting tool."
• Only filing an issue is a link; in the Figma mockup, the link is applied to the whole phrase: filing an issue in the Phabricator.
• Should there be a comma after persists ? as in "If the problem persists, consider filing an issue in the bug reporting tool."
• The error message is not an overlay

Figma - error message	eswiki beta

(3) The specific error handling is present (as it was mentioned in @sgs comment) but only as DRAFT. Do we have mockups accommodating the error messages?
Btw, being offline is not handled - no error messages are displayed to offline users.

I added test cases for checking error handling to T360971: [QA task] Community configuration test cases .

Thank you for testing, Elena!

(1) and (2) are fine with me. We have decided per conversations with DST to keep the message inline and not on top of an overlay. The error message also looks good to me since we have discussed Phabricator not being the only bug-reporting tool possible. I agree we should add a coma after 'persists'. @Sgs can this be added, please? (not urgent)

Regarding (3), and also responding to SG's comments above:

In T359928#9687975, @Sgs wrote:

We are not displaying any useful information to the user about where the error is coming from and what to do to fix it. For instance we would show the same message for an offline user and for a user that does not have permissions to write in the configuration. Should we display this information? cc @Martin, and if so, how should we display it? cc @JFernandez-WMF.

If there is some extra info about what the error is/where it is coming from and its (potential) solution I think we should be adding that to the copy of the error message. @Sgs Do we have an enumeration or a possible list of the errors that could come up?

1. How should we deal with long forms? In slack thread, Derek suggests to place the error at the end of the form rather than the beginning. While that helps a bit I find it a bit counterintuitive as a pattern, most MW forms seem to use the "top" for displaying this kind of information
2. If the error is a validation error, the nice UX would include higlighting and maybe scrolling to the appropriate failing field. What do you think? @JFernandez-WMF

Agree with displaying the message at the top since this is what is mostly used within our interfaces, and +1 to highlighting+scrolling to the field from where the error is coming from. Is this possible? Can we add it as a post-MVP task?

In T359928#9751547, @JFernandez-WMF wrote:

(1) and (2) are fine with me. We have decided per conversations with DST to keep the message inline and not on top of an overlay. The error message also looks good to me since we have discussed Phabricator not being the only bug-reporting tool possible. I agree we should add a coma after 'persists'. @Sgs can this be added, please? (not urgent)

Done!

Regarding (3), and also responding to SG's comments above:

In T359928#9687975, @Sgs wrote:

We are not displaying any useful information to the user about where the error is coming from and what to do to fix it. For instance we would show the same message for an offline user and for a user that does not have permissions to write in the configuration. Should we display this information? cc @Martin, and if so, how should we display it? cc @JFernandez-WMF.

If there is some extra info about what the error is/where it is coming from and its (potential) solution I think we should be adding that to the copy of the error message. @Sgs Do we have an enumeration or a possible list of the errors that could come up?

A complete list of errors is hard to foresee but we can do some high level bucketing:

• Network errors (eg: user is offline)
• Submission errors
  • API errors (eg: user is not authenticated)
  • Validation errors (see T363855: Improve validation errors wording and behavior)

So far, I think we can start simple by classifying errors between validation and the rest. Later we can improve and fine grain "the rest".

1. How should we deal with long forms? In slack thread, Derek suggests to place the error at the end of the form rather than the beginning. While that helps a bit I find it a bit counterintuitive as a pattern, most MW forms seem to use the "top" for displaying this kind of information
2. If the error is a validation error, the nice UX would include higlighting and maybe scrolling to the appropriate failing field. What do you think? @JFernandez-WMF

Agree with displaying the message at the top since this is what is mostly used within our interfaces, and +1 to highlighting+scrolling to the field from where the error is coming from. Is this possible? Can we add it as a post-MVP task?

Could you add design (including copy texts) and acceptance criteria for the "highlighting + scrolling" in T363855: Improve validation errors wording and behavior? Thank you!

Thank you @JFernandez-WMF and @Sgs for clarification!

To summarize

• Validation errors upon Submission will be handled in T363855: Improve validation errors wording and behavior

• Other errors, i.e. Network errors (eg: user is offline), API errors (eg: user is not authenticated) - should be there another task for that? I checked how VE and Special:EditGrowthConfig handle such errors:

	VE	Special:EditGrowthConfig
Network errors (eg: user is offline)
API errors (eg: user is not authenticated)		Special:EditGrowthConfig page will silently fail to save edits without any message to user.