Pluggable sharing interface

[epixa]

We have an inconsistent experience when it comes to the various methods that you can use to "share" what you're currently looking at in Kibana with other people. The short link and embed functionality are both present under the "share" link in the top bar, but things like creating a PDF of a visualization or exporting a search result as a CSV, both of which are sharing options in their own right, are not being implemented there. All of those options should be available in the same place, and I think the top bar is that best place to anchor that functionality.

First, we'd need to update the "share" UI to support many more sharing options. I sketched out my proposal for that interface.

When you click share, all available sharing options for the current page slide down:

When you click one of the sharing options, the rest disappear (maybe slide off to the right?), the selected option gets anchored to the left side, and that specific option's sharing functionality appears to the right of that:

When the interface itself supports other sharing options, then we can add an integration point to the sharing component so that plugins can add their own sharing options to specific pages within Kibana.

/cc @kimchy @uboness @alt74

[epixa]

I think the biggest challenge we'll have here is providing plugins a way to conditionally show their sharing options based on context. For example, the reporting plugin wouldn't want the "export to pdf" sharing option to appear on routes that it couldn't actually export to a pdf.

[uboness]

the first things we want to define here are:

• what are the items that the share functionality can relate to
• assuming these can be UI elements within a view, then we'd need some notion of "focus"
• every app may have default supported sharable functionality.. if no element in the app is "in focus" then that default sharable functionality should determine the share button behaviour - including, if an app doesn't have a sharable functionality, the share button should be disabled.
• if an app doesn't have a share functionality, nor any of its elements, the share button should not be shown.

Once we define the elements, from there on we could implement some sort of "marked" function that an element must implement to expose it share functionality (maybe something along the lines of Symbol.iterator)

[epixa]

The short url functionality will be available everywhere, so we shouldn't have to worry about the empty state.

One thing to consider here is that we can't draw the sharing boundaries on applications themselves since some sharing options will be defined by plugins but will actually appear on other applications (e.g. pdf reporting). Your idea about plugins declaring "focus" could be helpful here.

[bevacqua]

There's a number of things to think of here.

First off, we don't want to be blindly grouping things together based on an action. That's to say, we shouldn't shove things into the Share section just because they're moving data from one point to another. Everything could be considered "sharing" in that sense.

In terms of API design, I agree with @epixa about starting off with the centralization of what we currently have, and then moving to an API that spans apps, plugins, and Kibana core. I'll need to dig deeper into Kibana architecture for that; I'll try and create a document about the architecture - a drawing if anything - outlining how the different components interact.

In terms of "what" can be shared, I presume the API should involve exposing a pure function that, if present, takes parameters like route and returns an array describing the different ways that piece of data can be shared, where we have things like the sharing icon's image, tool name, and some way to render the UI for that particular share. That UI is then in charge of the sharing functionality being meaningful.

Taking @uboness' idea of using Symbol, a rough sketch of what I think the API may look like, to figure out whether I'm thinking in the right direction. Things not described by the API below but by @epixa would mostly be automatically managed by Kibana.

// A `thing` can have sharing options
thing[Symbol.for('kibana.sharing')] = (route) => {
  const csv = {
    title: 'Download as CSV File',
    icon: 'https://imgur.com/....',
    render (container, data) => {
      // <- attach some HTML into the (empty) container
      // <- the generated DOM should have events that handle the actual sharing
      // <- an API could be provided to `render` that facilitates common tasks related to manipulating `data`
    }
  };
  return [csv];
};

Things I'm unsure about are:

• What thing looks like, entry points and whatnot, need to dig into architecture more
• Should render be more Angulary? How? Why?
• What kind of an API render would benefit from?
• Maybe rather than re-executing the function whenever the route changes, there could just be a isVisible(route) method on the sharing item
• Same as above for isEnabled(route, ...)

[uboness]

I think the share menu should be somewhat minimal in what it shows... potentially just the action item (e.g. "Export as a Report", "Share Dashboard Link", "Export as CSV", etc...).

Next to that (and I know I might get some heat of this, but screw it), I think it's time to consider lightbox style dialogs.

When the user clicks on one of the share items, depending on the action, we can potentially open up a lightbox dialog where the user can continue "configuring" the action. For example, When the user clicks "Export as a Report", we can open up a dialog where the user can configure the report (perhaps the format, name, etc...). Same goes for "Share Dashboard Link", we can open up a dialog where we show the link an the user can copy it (similar to how google docs sharing works).

The whole "single share button" idea was largely inspired by apple sharing functionality (which works across their OSs). The nice thing about it, is that it's simple.

[Bargs]

It should probably be up to the receiver of the "share event" to decide how to react to it. Maybe we could provide a common lightbox element for the common, simple cases, but some apps will probably want the option of transitioning to a new page. To continue the native app analogy, some apps have simple pop ups when you share to them (think Google Inbox, Instapaper) while some transition to the full app (think Mail app, browser).

[uboness]

It should probably be up to the receiver of the "share event" to decide how to react to it. Maybe we could provide a common lightbox element for the common, simple cases, but some apps will probably want the option of transitioning to a new page. To continue the native app analogy, some apps have simple pop ups when you share to them (think Google Inbox, Instapaper) while some transition to the full app (think Mail app, browser).

++

[stacey-gammon]

Untagging design, I think the design aspect of it has already been fleshed out with the new K7 stuff. But having a way to add export plugins is still valid I think. The embeddable API and pluggable panel actions gives a place for export types on a single visualization, but not at the dashboard level.

That being said, dashboard should itself be an embeddable, so we could use that implementation layer - only the UI layer doesn't fit well in the context menu if you are on the dashboard app.

There is a similar problem with visualizations. The context menu panel actions make sense on the visualize app as well, but where to expose them? Embedding a visualization inside the panel chrome on the visualize app would look bad. So when we are thinking about the Embeddable API (#19875) we may want to think of a way to extend the UI representation of the pluggable panel actions so that it doesn't have to appear in the panel context menu, but the top nav... or something else...

[timroes]

This has been implemented now via the new Share API and also the Embeddable API. I will close this issue since we have a solid first version, and further discussion how the Embeddable API looks should take place in the above linked issue by Stacey.