Change 1006494 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/CommunityConfiguration@master] [WIP] Editor: add PageTitleControl component

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

Per discussion with @Urbanecm_WMF, we'll need a mechanism to define when a given config option is targeting this particular component. An option to achieve this could be by creating a schema definition, eg: PageTitle. So schema would look like:

"GEHelpPanelHelpDeskTitle": {
 "type": { "$ref": "#/$defs/PageTitle" },
},
"$defs": { "PageTitle": { "type": "string" }  }

Moving this task to blocked until we resolve T357718.

Change #1006494 merged by jenkins-bot:

[mediawiki/extensions/CommunityConfiguration@master] Editor: add PageTitleControl component

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

Tested on beta Especial:CommunityConfiguration/GrowthSuggestedEdits.

The list of suggestions displays the titles in black, not in blue (as links) as they are displayed in production:

eswiki beta	production

Also, the invalid input (no title match) is indicated red.

Note: eswiki beta doesn't have Help namespace

In T357712#9733920, @Etonkovidova wrote:

Tested on beta Especial:CommunityConfiguration/GrowthSuggestedEdits.

Thank you!

The list of suggestions displays the titles in black, not in blue (as links) as they are displayed in production:

eswiki beta	production

Also, the invalid input (no title match) is indicated red.

I think the OOUI version in production renders menu items as links, giving the opportunity to the user to navigate to the pages listed?, however the click event seems only used for selecting the item, I could not navigate to the page (I tried to open the link in new tab with Cmd + "click"). I don't think the new component needs to follow exactly the same UI/UX than the prior one. First of all because the "old" one is meant for use abroad MW while the new one is scoped to be used in CC forms (at least for now). @JFernandez-WMF could you review the interface and indicate design expectations for this?

Note: eswiki beta doesn't have Help namespace

How is it relevant for the test? Are you implying that the production one is filtering only "Help" namespace pages? It does not seem the case, at least in testwiki.

In T357712#9735052, @Sgs wrote:

In T357712#9733920, @Etonkovidova wrote:

Note: eswiki beta doesn't have Help namespace

How is it relevant for the test? Are you implying that the production one is filtering only "Help" namespace pages? It does not seem the case, at least in testwiki.

@Sgs - I agree that it's not quite relevant. It was a note to me that when it comes to testing namespaces controls (or links to some pages in specific namespaces), I'd remember that eswiki beta doesn't have any pages in Help namespace.

Also, I agree that the new component doesn't need to follow exactly the same UI/UX than the prior one - my testing summary just lists the differences between two forms.

Moving for @JFernandez-WMF review.
There are few questions:
(1) The list of suggestions displays the titles in black, not in blue (as links) as they are displayed in production:
(2) if there is no matched page, a suggestion is displayed in red

eswiki beta	production and enwiki beta

(3) as per @Sgs comment - a link from suggestions cannot be open in a different tab/window

(4) There are no required fields on forms associated with Special:CommunityConfiguration - is it a expected behavior? {

Thanks @Etonkovidova 🙏
As per the MenuItem specs in the Codex page, the label/title is displayed in black. I will check-in with DST if there is a different behaviour when the items are pages and come back to this task.

In T357712#9756028, @Etonkovidova wrote:

(4) There are no required fields on forms associated with Special:CommunityConfiguration - is it a expected behavior? {

@Sgs @KStoller-WMF Do we want to make these fields required?

! In T357712#9762690, @JFernandez-WMF wrote:
@Sgs @KStoller-WMF Do we want to make these fields required?

Yes, those should be required as they are part of the standard Growth features that all wikis have enabled.

In T357712#9756028, @Etonkovidova wrote:

Moving for @JFernandez-WMF review.
There are few questions:
(1) The list of suggestions displays the titles in black, not in blue (as links) as they are displayed in production:
(2) if there is no matched page, a suggestion is displayed in red

I just checked in with DST on this and this is expected behavior. Let's leave it as it is right now on beta with the black labels.

In T357712#9764750, @KStoller-WMF wrote:

! In T357712#9762690, @JFernandez-WMF wrote:
@Sgs @KStoller-WMF Do we want to make these fields required?

Yes, those should be required as they are part of the standard Growth features that all wikis have enabled.

Got it, I also checked in with Derek about this and the Codex guidelines don't recommend marking required labels with an asterisk (see https://doc.wikimedia.org/codex/latest/components/demos/field.html#optional-fields). We should indicate the optional fields in the form (meaning, I am guessing, every field besides the two in the Newcomer Homepage?)

Should we create a task for adding the 'optional' text in fields? cc @Sgs — the optionalFlag is incorporated in the Field component.

In T357712#9764750, @KStoller-WMF wrote:

! In T357712#9762690, @JFernandez-WMF wrote:
@Sgs @KStoller-WMF Do we want to make these fields required?

Yes, those should be required as they are part of the standard Growth features that all wikis have enabled.

Agreed, however to be able to do so we need first to resolve T360921: Support required properties in schemas

In T357712#9765356, @JFernandez-WMF wrote:

Got it, I also checked in with Derek about this and the Codex guidelines don't recommend marking required labels with an asterisk (see https://doc.wikimedia.org/codex/latest/components/demos/field.html#optional-fields). We should indicate the optional fields in the form (meaning, I am guessing, every field besides the two in the Newcomer Homepage?)

It might be a bit redundant in forms where all fields are optional but I don't have strong objections with the suggested pattern.

Should we create a task for adding the 'optional' text in fields? cc @Sgs — the optionalFlag is incorporated in the Field component.

Yes please 🙏 , but mind that the task will be blocked by T360921 as mentioned above.

The required/optional problem is not specific to the single page title selector, it's just a coincidence that this particular field is required and uses this component. @Etonkovidova can we mark this as resolved?