Hi @Sarai-WMF, could you assist with a design mockup for how the following error message should be displayed?

There is a message that indicates that agent_client_platform_family was added automatically by MPIC

While waiting for mocks , have used this
{F57536430}

@Sfaci

Hey @SGupta-WMF! Unfortunately, the image you attached is restricted. Could you please enable access so we can see it? Thank you!

Let's evaluate a couple of different ways in which we could indicate the addition of the default contextual attribute:

1. We could present the 'agent_client_platform_family' attribute as a chip that displays a "read-only" look and doesn't include a delete button. The problem with this approach is that we'd have to apply the same custom styles again to the Codex's Chip Lookup, which we'll use to replace our custom implementation, once available.

2. We could utilize the field's helper text or an inline notice message to give users a heads-up about the default addition of the attribute:

2.1. Helper text	2.2. Inline notice message

Since we might not be using Codex's "Field" component, these text elements are not available by default: I assume we'll have to recreate them following Codex styles. On the other hand, I foresee that none of these latter options will look great if applied to the current component (the text would be included below the chips), although the solution will improve visually once we replace our custom chip lookup.

3. Both solutions could be combined to likely ensure more clarity: As a user, I can see that a custom attribute has been selected for me, and have a clear explanation why.

Does any of these solutions sound good?

Thanks @Sarai-WMF ! I feel option 2.2 most feasible , @Sfaci What do you feel?
Also , Is there a way to indicate this in the instrument details vue as well?

I agree with @Sarai-WMF. None of them will look fine because of the current component we have (all selected contextual attributes are placed in the same place where we want to place the message) but I guess that's a temporary fix until we add the new component for this field. I guess all selected items will be place inside the field with the new component.

I think we have to keep in mind that, sooner or later, JS client library will add this contextual attribute automatically so it won't make sense to show it there because even MPIC won't add this attribute. That's why I wouldn't consider the first option. Other client implementation (PHP and Java) are already doing that and the user/instrument developer doesn't have to keep it in mind. It's something transparent for the user

So I think we should hide the contextual attribute and show the message to notify users about it (Option 2). When we include the new "official" component everything will look better. Regarding this option I think that the right component would be Message, right? -> https://doc.wikimedia.org/codex/latest/components/demos/message.html. I have seen there is a Notice Message that looks similar to the one that Sarai has shared here

@SGupta-WMF @Sarai-WMF T374742: Update Metrics Platform docs on required contextual attributes is pretty related to this task. There we were discussing about which contextual attributes are automatically added by the client libraries. In the case of the JS one, we have found that agent_client_platform and agent_client_platform_family are added automatically so I think we could expand the current task and consider agent_client_platform_family also as a contextual attribute that users don't need to add while using MPIC.

I think that, while exploring this, I have created a bit of confusion when talking about "mandatory attributes for event gate" and "attributes automatically added by client libraries". In theory agent_client_platform_family is the only mandatory attribute for the event agent but, as JS client library is adding this one and the other automatically, it doesn't make sense for users to add none of them manually when filling the baseline instrument form. I think our ultimate goal regarding MPIC should be make user life easier and avoid unnecessary work.

I'll mention also agent_client_platform in the ACs to include it for this work.

@Sfaci Related MR here https://gitlab.wikimedia.org/repos/data-engineering/mpic/-/merge_requests/105?resolved_conflicts=true

Hi @SGupta-WMF

I think that I explained me wrongly (again) in my last comment (https://phabricator.wikimedia.org/T374984#10183323), probably because I have been learning some details about the contextual attributes involved in this task while working on this. I think right now we are already in the right way. We found that agent_client_platform and agent_client_platform_family are already automatically added by the JS client library. That means that nobody needs to add them manually to be considered for the related instrument configuration. And that includes the user and also MPIC as a tool. I mean, we don't even need that MPIC adds automatically the fields because the client library will do it anyway.

So I would say the only needed work here is to remember this detail to the user and disallow to add them while filling the form. But MPIC doesn't need to add them in a transparent way.

I think that the ticket description is not clear (I'll update it) and I'll add also some comments explaining this to the current MR we are reviewing. I think that, based on what we know right now, we can remove some unneeded code

@Sarai-WMF what do you think we can do from the point of view of the design and user experience?

@Sfaci Understood , so we could basically remove code from MPIC which adds default values for contextual attributes.
But we will need the information messages so that user does not remove it accidentally.

@Sarai-WMF Here are some screenshots for added messages , let me know if they look fine.

Hey @SGupta-WMF and @Sfaci, thanks for sharing all the information!

I'm starting to question how relevant it is to display this information to users. Given that these default attributes are added via the JS library and not as part of the instrument configuration on MPIC. What would be the risks of only indicating this technical detail in MPIC's documentation instead of displaying a message on the UI? Could users make any configuration mistakes if they couldn't access information about these default attributes directly on the form?

In case we decided to still display the message on the UI due to relevant, please note that, as agreed:

1. The default attributes would not be displayed as chips. This is to prevent users from removing default configuration, and to save us time to include any necessary validation to prevent them from doing do. (I believe that the ticket's description is aligned with this already)

2. To avoid making the information too prominent (it's really not essential for the task at hand), the notice could take the shape of either a helper text or an inline message

Helper text	Inline message

I have updated the ticket title and description to include all we have decided as per slack discussion

@Sfaci I am closing the current MR and working on A/Cs mentioned in updated discussion.