Osquery Manager integration page lists 1,300 items in a table

[jonasll]

Kibana version: 8.1.0

Elasticsearch version: 8.1.0

Describe the bug: Osquery Integration page lists a 1,300+ item-long table which is not particularly consumable. It also doesn't use the full width of the page.

Steps to reproduce:

1. Head to [kibana_host]/app/integrations/detail/osquery_manager/overview

Expected behavior:
This table is unlikely required in the context of adding the Osquery Manger integration. A link to an adequate piece of documentation is more than likely appropriate.

Screenshots (if relevant):

[mostlyjason]

@melissaburpo does this impact UX for OSQuery users? Is it a priority for your team to address? I think this impacts all integrations, but it looks like OSQuery has a particularly high number of rows.

FYI @dborodyansky as a UX issue

[melissaburpo]

Hi @jonasll, @mostlyjason - Osquery Manager definitely has a high number of potential fields, due to the osquery schema, which is expansive. When users run a query, the results will include one or more of those fields, depending on the query they write.

The Exported Fields table is essentially a reference for all potential fields that could be returned by osquery. We added it to the readme, because it appeared to be a standard section for other Fleet integrations. I agree that this info isn't particularly useful when you're adding the integration in Kibana, but it's useful as a reference once you start using the integration. The issue is that the Kibana overview page and the integration documentation share the same source (the integration readme), so if we remove that section, it'll be removed from both sites.

One alternative could be to move the field reference from the readme into the Kibana docs for Osquery.

What do y'all think? Should we leave it where it is to follow the common integration pattern for field reference content like this (and fix the table formatting issue), or should we make an exception in this case and move it to the Kibana docs, due to the table's unusual length?

[jonasll]

I strongly believe this is a bad user experience today. It will not be used as a reference table. I can imagine that the pattern was originally established for much smaller scope responses. I would advocate for the removal on this page - it reflects poorly on the credibility and quality of the integration and product experience. Maintaining it on docs seems much more appropriate, if the Osquery docs themselves are not where we expect them.

[melissaburpo]

That makes sense. I'll work with the team to see if we can get this resolved for 8.2.

FYI @gchaps we may need to work together to figure out a good place for this reference content in the Kibana docs. We likely need to look into adding an Osquery sub-page for this.

[elasticmachine]

Pinging @elastic/security-asset-management (Team:Asset Management)

[mostlyjason]

Other integrations like system also have a large number of fields so a generic solution might be helpful. I agree this info is not useful for someone getting started. I've seen trial users scrolling these long pages in fullstory and I imagine they don't benefit in any substantial way. I have a hypothesis that an in-product reference info could be more convenient for existing users if we do it in a way that doesn't distract new users. Another problem is that its so long I can't see/navigate the various sections of the doc. I also can't see the headers so its hard to know what the columns mean.

As a brainstorm idea, what about putting the tables in a scroll window or using pagination with search? This would de-emphasize the tables while still leaving the info accessible, and make it easier to see persistent headers. I'm not sure how much work is involved in rendering this from markdown though.

Adding @akshay-saraswat who is PM for integrations ecosystem for input on a potential generic solution.

[akshay-saraswat]

• Another potential solution could be a tab dedicated to exported fields similar to the Overview tab.
• Searchable table would be awesome for sure but I think it would just be a nice-to-have requirement for the laptop users because cmd+F or Ctrl+F in any browser does a good job of page content searches unless it's collapsed. That's table stakes for browsers. For smartphone users, it would be a critical need, but as per Fullstory we only have about 6% mobile users, so, I wouldn't focus on it right now.

[melissaburpo]

I like the idea of a tab dedicated to exported fields. This would keep that info separate from the Overview, which makes sense, but it would also be available for reference if needed.

For Osquery Manager, I propose that we go ahead and remove the Exported fields for now, due to its unusual length, and if we decide to move forward with something like the new Fields tab as @akshay-saraswat has proposed, then we can add that content back at that time.