[Seamless] Improve the discoverability of common runtime field cases

[ryankeairns]

Summary

As an analyst or author, I would like the ability to add new fields during the exploration phase [insert definition of runtime fields] . Often (assumption), I would like to do relatively simple things like basic calculations, concatenation, duplication, map ranges, or split on a delimiter to generate a new field for my analysis.

Problem

While these things are currently possible, there are some obstacles in the current offering. First, for reasons, the runtime fields UI is somewhat tucked away in the field selector UI (Discover and Lens). Second, the user is faced with the near immediate ask to write a Painless script to create the new field [1].

Proposed solution

Withe the Pareto Principle in mind, focusing on 20% of the 'common' use cases may accommodate 80% of the desired outcomes. Parallel work is ongoing in AppServices which will provide users with more guardrails and, in turn, should provide us more confidence in elevating the discoverability of runtime field creation.

Combining these topics, we could add a more prominent button which exposes users, first, to form-based UIs that address the most common use cases with the current script-based approach positioned for custom/advanced cases.

Common use case UI in Discover

Sample UI-based field creation

[Unified Search] Alternative placement for triggering common use cases

[1] The RF creation flow - including the Painless scripting UX - is being addressed here

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServicesUx)

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[kertal]

closing for now, feel free to reopen, when to time is right (good thoughts here)