Related MR: https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/130

Change #1091784 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] Metrics Platform Instrument Configuration: Deploying to staging

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

Change #1091785 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/deployment-charts@master] Metrics Platform Instrument Configuration: Deploying to production

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

Change #1091784 merged by jenkins-bot:

[operations/deployment-charts@master] Metrics Platform Instrument Configuration: Deploying to staging

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

Change #1091785 merged by jenkins-bot:

[operations/deployment-charts@master] Metrics Platform Instrument Configuration: Deploying to production

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

The acceptance criterion of this ticket has been met and everything's looking good from a design standpoint 👍🏻 Just a couple of remarks:

1. [No action required] The placeholder of the "Stream name" field has a known typo that will be fixed when the copy is updated as part of T373907: MPIC: Improve application copy

2. [Decision needed] Unfortunately, due to the original lack of design specifications, the behavior of the "Stream name" field, though acceptable, could be improved. The original requirement said that the field should become read-only when prefilled, but its default state wasn't specified and unfortunately read-only is not fitting in this scenario. From the point we're at, we could:

• Make the "Stream name" lookup active by default, and change its state to read only once it is populated (i.e., when users select the options App or Web base)
• When users interact with the default active lookup and select a custom schema, then the "Custom" option could be automatically selected for them to simplify the input of information. (This is a more flexible alternative to displaying a default disabled field that becomes read-only when the app or web base options are selected, and turns active when custom is selected)

These changes are not critical, just fixes that would make the interaction smoother. My assumption is that they should be documented in a separate ticket. Looking forward to your thoughts on this, @VirginiaPoundstone, @Sfaci and @cjming.

The MR has been merged and deployed. @VirginiaPoundstone @Sfaci @cjming: Could you weigh in on @Sarai-WMF's comment above so that a new ticket can be created and this can be moved to Done?

hi @Sarai-WMF - is it reasonable to expect that users would select a Schema type before clicking into the Stream name text field? Maybe it's still not ideal to have Stream name in a read-only/disabled state if a Schema type has not yet been selected?

Your first suggestion

Make the "Stream name" lookup active by default, and change its state to read only once it is populated (i.e., when users select the options App or Web base)

This scenario would assume that an active Stream name field correlates to the Custom radio button - if we take this route, it would make sense to have the default Schema type be Custom (which is basically your 2nd suggestion) which from what I understand isn't what Metrics Platform wants to encourage -- i.e. AIUI we want to funnel most people to use App or Web base schema types.

Your second suggestion

When users interact with the default active lookup and select a custom schema, then the "Custom" option could be automatically selected for them to simplify the input of information. (This is a more flexible alternative to displaying a default disabled field that becomes read-only when the app or web base options are selected, and turns active when custom is selected)

This approach makes more sense to me but again, by making the Stream name field active by default means that the Custom option is selected by default in the Schema type field.
Is this really what we want?

Happy to spin up a follow up ticket for this work - just want to make sure we understand the implications of making Custom the default schema type.