[Uptime] Remove external links to docs, try and document inline where possible.

[andrewvc]

When users do not have a geo location configured in Uptime we link externally to documentation showing how users can add it, however users of the app may not have internet access, in which case the links are useless.

It makes sense to me to have a short version of these docs available in a popover directly in the app, but I'm worried about maintenance of the docs.

Alternatively, have we considered shipping the docs with Kibana? @bmorelli25 @drewpost @katrin-freihofner would love to hear your thoughts.

CC @eddieturizo

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[bmorelli25]

I think things like this are very useful for our users. Maintenance is a real concern though, and right now we don't have any way to track Kibana popovers/tooltips/notes to ensure we're updating them when they need to be updated.

Alternatively, have we considered shipping the docs with Kibana?

Tagging @dedemorton for insight on this one. I'm sure it's been brought up in the past.

[dedemorton]

I love the idea of embedding meaningful content directly in the UI. But we need to come up with a plan for where this "embedded" content will live so that a) writers will know to update the content when functionality changes, and b) developers won't overlook it when they are updating related docs. I'm pretty sure that most developers updating Beats, for example, won't look for source that's outside of the beats repo.

Tagging @gchaps for input, too. I'm not sure which options are available in Kibana for providing embedded assistance (or what's planned).

[andrewvc]

@dedemorton that makes sense. Maybe the best solution here is to allow users to host their own docs (somehow) and let them configure kibana with an alternate root URL for docs.

That's obviously way outside the scope of uptime, but still seems worthwhile.

[gchaps]

In Kibana, we provide in app help using tooltips, placeholder text, hint text, and other short descriptive text. I think we should provide this type of help wherever it makes sense for the user.

I'm not sure how useful a larger popup with docs would be. Users tend to scan the text in the UI.

`ccing @mdefazio from design for input too.

[mdefazio]

Without knowing to what extent the 'short' version of the docs would be, I tend to think that we can try and provide enough help text through tooltips, placeholders, etc. within the UI, but longer form should probably be on the docs site. I think it's nice to have a single place to direct someone.

[justinkambic]

@andrewvc if we’re specifically talking about monitor location name, that is a setting that is terse enough we can probably provide a code example alongside the docs link. This wouldn’t work in every case obviously, but for this setting I think it would be ok. WDYT?

[andrewvc]

@justinkambic The individual setting is pretty short, but the docs are a good bit longer.

Maybe we could do a mix of both, keeping the link and adding a message like below:

Geo metadata missing. Use the add_observer_metadata in your heartbeat.yml file to track geo locations. See docs for more info.

@bmorelli25 @dedemorton WDYT about the above compromise? ^^ CC @drewpost

[dedemorton]

@andrewvc I like that approach because it gives just enough info for users who are already familiar with beats.

[bmorelli25]

Edited your link as it was 404ing ^

Maybe we could do a mix of both, keeping the link and adding a message like below:

Yup, that's what we do in the APM app 👍