[Watcher] Clarify meanings of the various Watch states

[elasticmachine]

Original comment by @bohyun-e:

!LINK REDACTED

I asked in Slack on what the difference between OK and Firing was. @ycombinator responded:

OK = none of the actions are being executed | Firing = at least one of the actions is being executed

It would be great to have those as tooltips because it's not very obvious what each state means. It looks like we also have "Error" and "Disabled" state?

Related: LINK REDACTED

cc: @w33ble @BigFunger @skearns64

[elasticmachine]

Original comment by @w33ble:

May be better to just have a legend under the table or something explaining the states. Just a thought.

[elasticmachine]

Original comment by @bohyun-e:

May be better to just have a legend under the table or something explaining the states. Just a thought.

Was going to mention this but did not. I like the legend idea better.

[elasticmachine]

Original comment by @skearns64:

Thanks for raising this! I would imagine that we'd like to make decisions like Tooltips vs Legends (vs Clippy vs. Merlin?) at the stack level, and only diverge when appropriate/necessary.

@snide - This is likely to be a common problem for tables across Kibana: columns and values that need a little describing. Is this something the design team has tackled, or is there a place we should create an issue to track this?

[elasticmachine]

Original comment by @snide:

I say this not knowing if "firing" is a documented namespace in ES.

I generally like legends if we're only dealing with a couple events. In this specific example I think just changing your language can remove the need for tooltips. "OK" is often thought of as a vague status.

"At work" and "Ready for work" would likely better describe what's happening here.

I'd also suggest not using a yellow action for "At work" because it's not a warning action, it's just something that's going on. Likely green for "At work" and a neutral for "Ready for action". If this is a polled page, I small spinner for "At work" can further cement the idea.

If you want, can just assign to me and I'll give you some better icons / wording.

[elasticmachine]

Original comment by @skearns64:

@snide - Thanks for the guidance. Happy to have your input here, though we'll have to bring you up to speed on Watcher before this will all make sense, I'm afraid. I don't think we need to rush in a change for 5.4, as this page will continue to evolve as we add new capabilities (like more types of watches that have their own editors, etc).

Watcher is commonly used for alerting, but can also be used for automation (this will become more of a thing in the future as well). Each Watch has a trigger (how often should this thing run), input (when it runs, go run this search, make this API call and grab the results, etc), condition (can be a script or just an expression based on the input) , and an array of 0 or more actions, each of which may have it's own condition.

I suggest we find a time to walk/talk you through the Watcher UI, to make sure we have a shared understanding of the problem space, and can think about improvements from there?

[elasticmachine]

Original comment by @snide:

Sounds good.

[elasticmachine]

Original comment by @BigFunger:

From @ycombinator LINK REDACTED

In a future PR, probably as part of addressing LINK REDACTED:

• Combine the status + ID columns, using an icon for the status + a tooltip that explains it. For sorting that column, use the sort order of the name.
• Introduce a filter for the status, so users can narrow down the list to watches that are firing, or watches with errors, or watches that are OK, or all watches (default).
• Move the comment under the ID, so its close to the status icon (since the comment is a comment on the status, kinda like a sub-status).

[elasticmachine]

Pinging @elastic/es-ui

[cjcenizal]

I think the best solution to this issue would to add a EuiIconTip with a question mark icon next to each state to explain what it means.