[Setup UI] Distinguish between setup states

[ycombinator]

I'm running a cluster that's using internal collection for monitoring. Here's what the cluster's overview page looks like in setup mode:

Notice the 0/1 with the danger background. And also notice the tooltip text suggesting that the 1 node doesn't have monitoring setup. However, monitoring is setup; it's just not Metricbeat-based.

I wonder if we should change the counts (to be 1/1 in this example), background color, and/or tooltip text to indicate the setup state more clearly in this scenario?

[elasticmachine]

Pinging @elastic/stack-monitoring

[cachedout]

I agree completely. +1 on setting this to 1/1 and changing the background color to something like yellow, at a minimum.

[yaronp68]

I agree with showing 1/1
Warning / Info in case cluster is using native monitoring (local or http) should be added IMO, once we can support all types of installations: self-managed and cloud

[chrisronline]

What do we think about something like this below. I'd hide the tooltips that have count 0 (but currently have them all showing 1 to illustrate all possible states)

[cachedout]

I believe a grammatical change is necessary for the second tooltip. The second sentence currently reads, Click 'Nodes' and perform the recommended setup action to exclusively set up Metricbeat collection for these nodes.

I propose that this be changed to: Click 'Nodes' and perform the recommended setup action to *set up* Metricbeat collection *exclusively* for these nodes. (I surrounded the changes with asterisks.)

This better correlates the word exclusively with the type of monitoring being set up and it changes setup to set up when it is an action. (Though, I don't know if we have a style guide that has an opinion about the latter change. @lcawl ?)

[cachedout]

Also, should one need to click Nodes to perform the action in the second and following examples? What if they could just click on the box which has launched the tip?

[chrisronline]

Sure, we can make those changes. Do you think, with those changes, the overall UX is better/well understood? Or should we go another direction?

[cachedout]

@chrisronline That's a good question. My initial reaction, to be honest, is to say that we can improve this though I'm not (yet) certain how. Let me try to elaborate on my concerns.

I think that as it sits, it's necessary to hover over the colored boxes and then to read each tooltip in order to know what they are at all. This means of interacting with them feels just sort of initially confusing. Perhaps if they had a title alongside or above indicating their purpose this could be made easier to understand at first glance?

[yaronp68]

@chrisronline Red and Yellow have a meaning of Error and Warning. Do you regard to native local collection as an error? Do you see double monitoring as a concern? Is it only when we see the metricbeat reports locally?

[chrisronline]

Thanks for the feedback all!

I chatted with @cchaos (thanks again!) and we talked through a potentially simpler solution. I think the sole purpose of any UI changes on this page is to inform the user they might need to take action in the relevant listing page. We mine as well just show one of two states:

• Nothing (if all of their nodes/instances are monitored via MB)
• A flag icon with a simple tooltip (which also serves as a link to the listing page), otherwise

Something like:

WDYT?

[cchaos]

👍 My only concern is the "Click for more information" text. If you're just taking them to the Nodes listing page it won't be obvious as to what information they should be looking for. I'd suggest something more descriptive like "Click the flag icon to visit the Nodes listing page and select those you with to migrate"... or something. Maybe get with @gchaps over language.

[yaronp68]

I like this UX

[chrisronline]

@cchaos I've updated the copy to:

Some instances are not monitored by Metricbeat. Click the flag icon to visit the instances listing page and find out more information about the status of each instance.

I'll make sure to consult with @gchaps on the final PR (which isn't up yet) to iron out any and all copy issues

[chrisronline]

These changes are now available in #40442.

EDIT: This is not longer true. Changes are in this PR: #41725 (comment)

[cachedout]

I like it. My only question is consistency throughout Kibana (and the Stack Monitoring application). Is the flag in use anywhere currently? If so, are there examples we can see? (This is probably a question for @cchaos )

If this is the first use of the icon, will it be reserved for this kind of informational use going forward or is it subject to change?

I'm just hoping that we can ensure that it doesn't mean something in the Stack Monitoring application and something dramatically different somewhere else. :)

Other than that, 👍

[chrisronline]

PR up for these changes for Kibana and ES (as the beats/logstash/apm changes are not in master yet): #41898

[chrisronline]

@cachedout Fair point. I didn't decide on the icon myself, so I'll let @cchaos weigh in. AFAIK, we don't use this icon anywhere in monitoring currently.

[cchaos]

It's really up to the app owners to place meaning on individual icons. Flags are usually just used as general indicators of something that needs attention.

[chrisronline]

Thanks @cchaos

I think we're in a safe position to start using the flag icon, as it's a little different than the alert icon (which we use in the cluster alerts UI).

Any issues moving forward with this, @cachedout (or anyone else)?

[cachedout]

👍 from me