Bringing @Sgs's question here on how to handle the case of multiple changes being made and how we represent that in the preview.

I think the "diff" preview might be challenging to display when several changes have been made. @JFernandez-WMF do you have advise on how could we handle that situation?

If there are multiple changes, I suggest making the dialog scrollable — this is something that Codex already has incorporated in the Dialog component.

@Sgs what are your thoughts?

In T358035#9596398, @JFernandez-WMF wrote:

@Sgs what are your thoughts?

What should happen if the user clicks on "Save changes" without filling the summary? I'm not convinced of the fact the Reminder block is not seen 🤔

Looking at the “diff”, it’s everything but a diff – a diff highlights the differences, i.e. both the old and new values. Could this “diff” be modified to show the old values as well?

Thank you @Sgs for pointing that out, and @Tacsipacsi for your great input.

This was discussed and maybe 'diff' was the wrong word to use in this task, however a design that includes an actual diff view was explored. We could have this dialog with only the edit summary (which could maybe alleviate the issue of the Edit Summary not being visible if multiple changes are made) and a 'Review your changes' button that takes the user to the diff view. @Sgs / @Urbanecm_WMF could this be possible from an Engineering stand point? @Tacsipacsi would this address your comment?

I’m okay with displaying the diff on a different screen, as long as it’s a real diff.

With these changes, your mockup is quite similar to, yet different from, the VisualEditor save dialog.

Would it be possible to align the both (close button top left, save/publish button top right, diff button bottom left, edit summary is a textbox rather than a single-line input)? Maybe the minor edit and watchlist options could also be provided, although they may not make as much sense from a user viewpoint as in VisualEditor. (However, a typo fix could still be a minor edit, and one may want to watch the MediaWiki-namespace page they’ve just edited.)

thank you @Tacsipacsi, as Kirsten mentioned in https://phabricator.wikimedia.org/T354463#9613637, the Visual Editor dialog has been built with OOUI, and we are determined in using Codex for Community Configuration. You can take a look at the Codex's dialog specifications here.

I am also gently pinging @Urbanecm_WMF and/or @Sgs to see if it is possible to link to the actual diff view from the dialog.

In T358035#9623933, @JFernandez-WMF wrote:

I am also gently pinging @Urbanecm_WMF and/or @Sgs to see if it is possible to link to the actual diff view from the dialog.

Thanks for the ping. We should have both the new and old config available when saving the new config, so building a diff view should definitely be possible. We can display it similarly to what VisualEditor does, by replacing the Save form by a diff view, and offering the user the option to go back, see screenshots:

Save form	Diff view

We can have something similar: maybe a table with previous and new value? In that case, we would still stay in the same dialog context (which is the important part from an engineering perspective), but we can have different screens/windows in the edit form and display different information in each. Using this space for displaying diff makes a lot of sense to me.

In T358035#9633558, @Urbanecm_WMF wrote:

We can have something similar: maybe a table with previous and new value?

You may be inspired by the Wikibase diff view, which also compares fields rather than lines of text:

(this is my mockup, showing how I’d like it to look like rather than how it actually looks like, but it’s close to the reality).

thank you both for your input here! I've mocked what it would potentially look like to add the diff to the save dialog. I adopted the diff type that we already have on test.wiki (example), I do think we need to improve the way this is represented though and make it more intuitive, but I don't know if there is time for that before the first release.

please share any thoughts you have! cc @KStoller-WMF

save dialog	'review your changes' dialog

• Save dialog:
  • As @Sgs pointed out in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityConfiguration/+/1011094/comment/6b09c1a9_524a8ce1/, the placeholder in this design says Placeholder, which doesn’t make sense. (The patch used the copy Describe the changes that were made in the configuration instead.)
  • @KStoller-WMF agreed with me in T354463#9625135 that the (optional) label is odd.
• ‘Review your changes’ dialog:
  • The back button could have a text label rather than an icon. While the icon fits the OOUI design well, it looks strange to me in Codex.
  • In OOUI, the place of the close button is occupied by the back button. This is not the case in Codex, so maybe a close button could be added to the diff dialog as well? (This would also make engineering easier, as @Urbanecm_WMF said in T358035#9633558 that the two dialogs would technically be one, so the less differences, likely the easier to implement.)
  • The mode changer in the design is wikitext-specific and not applicable to JSON (which is what’s being edited here). Options:
    • Just remove it.
    • Change the options to Structured and JSON: JSON is what we see here, while Structured is a structured view, similar to the Wikibase diffs, allowing admins to not care about JSON at all if they don’t want to (which is the whole point of Community Configuration); this would be the improved and more intuitive diff you mentioned.
    • Remove it for now, introduce the Structured option as time allows.

In T358035#9656276, @Tacsipacsi wrote:

• Save dialog:
  • As @Sgs pointed out in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommunityConfiguration/+/1011094/comment/6b09c1a9_524a8ce1/, the placeholder in this design says Placeholder, which doesn’t make sense. (The patch used the copy Describe the changes that were made in the configuration instead.)

Thank you! I just updated the mock-up.

• @KStoller-WMF agreed with me in T354463#9625135 that the (optional) label is odd.

I completely agree with this, however I raised this with the Design System team commenting our specific use case, and it has been recommended for us to still use the (optional) label. An alternative they suggested is to reinforce the importance of the edit summary a little bit more by adding a description that says that 'entering an edit summary is highly recommended'. @Tacsipacsi Curious to know your thoughts about this approach?

• ‘Review your changes’ dialog:
  • The back button could have a text label rather than an icon. While the icon fits the OOUI design well, it looks strange to me in Codex.
  • In OOUI, the place of the close button is occupied by the back button. This is not the case in Codex, so maybe a close button could be added to the diff dialog as well? (This would also make engineering easier, as @Urbanecm_WMF said in T358035#9633558 that the two dialogs would technically be one, so the less differences, likely the easier to implement.)

I added this to the mock up as well. Thank you!

• The mode changer in the design is wikitext-specific and not applicable to JSON (which is what’s being edited here). Options:
  • Just remove it.
  • Change the options to Structured and JSON: JSON is what we see here, while Structured is a structured view, similar to the Wikibase diffs, allowing admins to not care about JSON at all if they don’t want to (which is the whole point of Community Configuration); this would be the improved and more intuitive diff you mentioned.
  • Remove it for now, introduce the Structured option as time allows.

Thank you for the thorough explanation on this! Very appreciated :) I removed the switcher. I think we could work on the structured option you mention as post-MVP, so we can add the switch later for JSON + Structured.

Commenting the last version here based on this discussion. Feel free to raise any other suggestions, otherwise I am happy to resolve this.

In T358035#9663753, @JFernandez-WMF wrote:

• @KStoller-WMF agreed with me in T354463#9625135 that the (optional) label is odd.

I completely agree with this, however I raised this with the Design System team commenting our specific use case, and it has been recommended for us to still use the (optional) label. An alternative they suggested is to reinforce the importance of the edit summary a little bit more by adding a description that says that 'entering an edit summary is highly recommended'. @Tacsipacsi Curious to know your thoughts about this approach?

Where would you put that description? There is already a description below the input field that stresses the importance. Another option would be simply replacing the (optional) label with (recommended), which communicates that it’s not required but still highly recommended.

Other than this, it looks good, thanks!

I've added the follow-up engineering task: T361542: Community Configuration: add "Review your changes" diff to Edit Summary dialog