[Infra] Universal Profiling feature activation

[crespocarlos]

Summary

Similar to https://github.com/elastic/kibana/issues/175542, we want to align the experience around features that are behind feature flags. The Universal Profiling tab, when the feature flag is turned off, needs to follow the same design idea from below:

(link to figma)

AC

• When the feature flag is disabled, the tab will appear following the designs above
• "See more" links to https://www.elastic.co/guide/en/observability/current/analyze-hosts.html

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[crespocarlos]

@roshan-elastic we probably need a new copy for the universal profiling case.

[cauemarcondes]

That message is not user-friendly, don't you think? I say that because currently, if I'm not mistaken, we show this message to the user.

IMHO it gives an overview of what this feature is and a link to the docs where they can learn more. I see you also have the learn more link though.

[roshan-elastic]

Thanks @cauemarcondes @crespocarlos.

Question : Is Universal Profiling disabled or enabled by default?

[crespocarlos]

It's enabled by default. @roshan-elastic , With that in mind, should we implement the same flow for universal profiling too?

[roshan-elastic]

It's enabled by default. @roshan-elastic , With that in mind, should we implement the same flow for universal profiling too?

Cheers @crespocarlos is it easy enough to apply the same logic when disabled? If it's good house-keeping to keep it consistent, let's add the lock on it and show a disabled message.

If it's a fair bit of work...we can prioritise this for another time...

I figure it would be nice to set a best practice for things when users turn them off if it's easier to start now than later.

[crespocarlos]

@roshan-elastic SGTM. Should we change anything in the copy?

[roshan-elastic]

Hey @crespocarlos,

I've quickly mapped out what happens today in profiling:

Profiling experiences within Hosts by use case - current behaviour

I think if we are going to add in a 'disabled by admin' state then we should at least preserve the splash screen to encourage users to ask their admin to enable it. For example:

Disabled state

Enabled but requires onboarding state

Just to take a step back...

Do we actually need to make any changes right now?

I think the current behaviour serves most users (all we're losing is awareness of the feature if it is turned off).

It would be good to have a 'disabled state' available for profiling but unless it's really fast to agree on a wider design pattern for disabled states etc (and deploy it for profiling) I think we should deprioritise this for now.

See FigJam with current vs proposed changes

[crespocarlos]

Hey @roshan-elastic , thanks for this

I think the current behaviour serves most users (all we're losing is awareness of the feature if it is turned off).

It would be good to have a 'disabled state' available for profiling but unless it's really fast to agree on a wider design pattern for disabled states etc (and deploy it for profiling) I think we should deprioritise this for now.

I don't believe this needs to be prioritized now. I think the main point is to have a standard experience around feature activation, especially on feature awareness.

[roshan-elastic]

Cheers @crespocarlos - let's deprioritise for now.

cc @cauemarcondes - see above couple of comments.

[cauemarcondes]

Thanks @roshan-elastic / @crespocarlos , I liked the decision posted on this comment. https://github.com/elastic/kibana/issues/178218#issuecomment-1985556244

IMHO keeping the splash screen makes things more personal and user-friendly. Adding the adm message makes even more sense in this case, as the user won't be able to add UP.

Thanks for that.

[botelastic[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.