Kibana: Kibana Help Dropdown to include “Get Help” and/or “Give Feedback”

[bmcconaghy]

These new buttons/links should take the user to a custom form.

Get help would be a simplified version of a contact-me, with a page design and language that makes it clear they came to the right place.

Give Feedback would be a minimal form with required email address, feedback text box, and a checked-by-default opt-in to our mailing list.

We will need to focus on the design of these forms with marketing to make sure design quality is appropriate, and they feel like a natural place to land coming from Kibana.

[skearns64]

On "Get Help" - worth noting that if we can detect that we're running in ESS, it would be good to redirect to support, instead of a custom form. If that's not practical this timeline, @alexfrancoeur - let's think about the design of the form. e.g. an "Already a customer? Open a support case here!"

[mikecote]

Few questions on my end:

• These custom forms, will it be an external link to them outside Kibana or developed in Kibana?
• Is there any other links / features we want to add to the help menu or I’m good to talk with design team about the changes?
• Is there features in Kibana already that change when detecting a specific environment vs another (ex: ESS)? I can take a look at how it detects. Otherwise I will find out what it would take.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[cchaos]

Does this mean also changing the way individual plugins link to some sort of "Give feedback"? Like Lens, which currently directs to Github.

Or Is this meant to be a new Kibana-wide link that would be listed under the Documentation link? If it is not replacing individual app links for feedback, how do we differentiate between general feedback and app-specific? I am currently working a better layout of this help dropdown to accommodate the influx of new links, so I'll be able to help with the UI.

It would be great if this link would not take users out of their current context, but is a form that occurs within a modal that they can submit and then get right back to what they were doing.

[alexfrancoeur]

On "Get Help" - worth noting that if we can detect that we're running in ESS, it would be good to redirect to support

@skearns64 ack. I know we have mechanisms to detect ESS, we use these in the add data UI. It feels like this should be possible, what do you think @mikecote?

@mikecote some answers below:

These custom forms, will it be an external link to them outside Kibana or developed in Kibana?

Yes, these will be external. We'll get you the endpoints soon.

Is there any other links / features we want to add to the help menu or I’m good to talk with design team about the changes?

Not that I can think of at the moment, but we probably want to work with @gchaps on the current text: "Get updates, information, and answers in our documentation.". This UI feels like it's more than that now. I think we're good to involve design, though it looks like @cchaos has already replied 😉

Is there features in Kibana already that change when detecting a specific environment vs another (ex: ESS)? I can take a look at how it detects. Otherwise I will find out what it would take.

The Add Data UI does this. We adjust the instructions based on deployment. @nreese might be able to provide some insight here.

@cchaos some comments below:

Or Is this meant to be a new Kibana-wide link that would be listed under the Documentation link?

This is meant to be a kibana-wide link, but I wonder how much work it would be to pre-populate the form based on context. For instance, adjust the subject based on the application your in. So if you provide feedback from lens, the subject would say "Lens feedback" or something along those lines.

how do we differentiate between general feedback and app-specific?

We could rephrase the text to be more related to GitHub. @gchaps can probably help with this, but we could say something like "Notice something odd or have an enhancement request? Open an issue in our Github repo". This way there are two lines of feedback. I think they're different. One is a mechanism for general and direct feedback, another is to create an issue to track progress on a specific request or bug.

[mikecote]

@alexfrancoeur I took a look at the add data UI. I can see it changes the instructions when cloud is enabled. There's an easy to access variable that determines this and I can display something different in the help menu using that approach. cc @skearns64.

[alexfrancoeur]

Sounds good @mikecote thanks.

This is what we're planning for endpoints:

• elastic.co/kibana/gethelp - title: "Get Help"
• elastic.co/kibana/feedback - title: "Kibana Feedback"

For ESS the support endpoint is: support.elastic.co

I'll let you know if anything changes.

[mikecote]

For reference purposes (not a proposal) I put a mock of what the two links look like in context. I will adjust the UI once @cchaos has a design with the new links and I will change the wording once @gchaps has suggestions.

[cchaos]

@alexfrancoeur As @gchaps and I are talking about the language for this dropdown, we're still confused as to why there are two separate links for "Get help" and "Feedback". We don't quite understand the differentiation or why they require two different forms. If they go to different places, it seems like this could be something applied on the form itself and not necessary to determine at this level.

We are also considering what this means when other plugins add in their own links for feedback and documentation. Currently, plugins point to the general Kibana Github repo so users can open a ticket and while it lives under the plugin's specific heading, it doesn't actual lead to a plugin specific location.

Therefore, it seem like we should be able to combine some efforts here to make sure it's not confusing users more to figure out where to go for help vs feedback, etc.

[alexfrancoeur]

we're still confused as to why there are two separate links for "Get help" and "Feedback"

I can see how they might be confusing. At the moment, the endpoints are fairly close to being locked in so if we decide to change any text in Kibana, the URLs may not match. Let me explain the differences between the two links, because the content in the forms will be different.

Get help is essentially a simplified version of the contact me page. The page and design language will make it clear they came to the right place, but the form is essentially asking someone to reach out to them to help answer any questions.

Give feedback would be a would be a minimal form to provide candid feedback while not looking to be contacted at all. Simply providing feedback, possibly with a subject line that can be pre-populated based on the context you're in.

I'll be working with @VijayDoshi to detail provide the fields for these forms but at the moment, we are aiming to have two separate forms / use cases.

We are also considering what this means when other plugins add in their own links for feedback and documentation. Currently, plugins point to the general Kibana Github repo so users can open a ticket and while it lives under the plugin's specific heading, it doesn't actual lead to a plugin specific location.

I think this could be handled in a few ways. We keep the generic Kibana stuff linked above, and we can provide contextual custom links per application / feature. Docs go to the appropriate docs, and we could provide a Give feedback for X to link to the give feedback endpoint, but possibly fill in a subject or field in the form. We may also be able to do something similar for GitHub, Open issue for X. Where instead of linking to the generic Kibana repo, we link to a templated create issue form and append a label for the feature or product.

Given the proposal above @cchaos @gchaps, could we split the the ask a question / give feedback links into two? The still feel like separate use cases. Maybe "Get help" is the wrong verbiage, so I'd be open to any other suggestions now that I've explained the purpose of these links a bit more

[gchaps]

@alexfrancoeur, @cchaos How about either of these two:

Help
Kibana 8.0 documentation
Ask us
Give feedback
Open an issue in GitHub

Uptime
Documentation
Give feedback on Uptime

---

Help
Kibana 8.0 documentation
Ask us a question
Give feedback on Kibana
Open an issue in GitHub

Uptime
Documentation
Give feedback on Uptime

[cchaos]

Here is the latest mock based on @gchaps' suggestion, which after talking offline we also decided to keep the Kibana versioning number in the header of the popover.

[mikecote]

@cchaos I have the following now with EUI components:

[mikecote]

I didn't touch the Uptime section. Are we suppose to change all the app's specific help sections as well? I believe there's 4 places using custom help sections.

[alexfrancoeur]

@mikecote nope, thats on the app. Anything below the general stuff is app specific.

[cchaos]

Moved over to PR for UI-specific feedback. https://github.com/elastic/kibana/pull/49797

[alexfrancoeur]

I see we landed on "Ask us" instead of "Get help". @gchaps just curious, what was your thinking here? I think @cchaos eluded to it previously, but is it just not obvious enough what "Get help" is? @VijayDoshi and I will be working on the forms for these endpoints soon and we'll need the header to match the text here. Right now the URL end-point is get-help and we may still have time to change it if needed. Worse case scenario, the URL route doesn't match the content of the page.

The options I see here so far are :

• Get help
• Ask us
• Ask us a question

What are the thoughts on either of these?

• Get help from Elastic
• Ask Elastic
• Ask Elastic a question

@VijayDoshi do you have any preference?

[alexfrancoeur]

We still have time to change the URL, "Contact us" isn't off the table either but feels too official. I'm feeling like "Ask Elastic" is a bit more straight forward than "Ask us". What do you think @gchaps?

[gchaps]

@alexfrancoeur To me "Get help" sounds like it opens a help topic in a web browser. It also sounds very similar to Kibana documentation. I don't feel that "Contact us" implies that its for asking a question of Elastic.

However, including Elastic in the text addresses my concern because it indicates that you are getting help directly from Elastic and not from a help topic . (I'm conflicted about "Ask Elastic a question" because "ask" by itself means asking a question). Here is what I think, in order of preference:

Ask Elastic
Get help from Elastic

[alexfrancoeur]

Thanks @gchaps, let's go with "Ask Elastic". @mikecote can we make that change?

[alexfrancoeur]

@mikecote endpoint will be changing to /kibana/ask-elastic

[mikecote]

Thanks @alexfrancoeur. You can find the updated screenshot here: https://github.com/elastic/kibana/pull/49797#issuecomment-551982513.

I want to confirm that "Ask Elastic" will still have the same text in cloud but would redirect to support.elastic.co?

cc @gchaps