[Data Views] UX: Improve sharing across spaces

[mdefazio]

Improve Data view sharing across spaces

If I have a data view in one space, I would like to be able to share that across multiple spaces.
This design issue will build off the existing work from #123991 to fix some UX concerns.

Target: 8.2

Questions to help drive our updates:

1. Are we able to determine when a Data view was updated in another space?
   If we were to show a Last modified timestamp on the data view, would this reflect changes from other spaces?

2. Are we able to show which spaces the data view is available in?
   Assuming the user has access to the other spaces, can we show that space badge? If the user does not have access, do we add +X indicating it is at least in other spaces?

3. How can we improve the potential for duplicate titles when sharing to other spaces?
   If I share a data view to a space with that data view already in it, there is no check for the same title currently.

4. How can we improve the delete confirmation?
   When I delete a data view, there is currently only a simple dialog explaining this will effect other spaces. We should improve the copy and UI here so it's clear this will delete the data view from all spaces. We can reference the saved object flow here perhaps.

---

Designs

Data views index page:

Delete modals:

Share flyout:

---

Next steps

• Complete design spec
• Create wireframes with proposed changes

[elasticmachine]

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

[mdefazio]

@mattkime Put this together just as a starting point. Some of these are questions, and some are kind of notes-to-self. Mostly around understanding our technical restraints for this work

[elasticmachine]

Pinging @elastic/kibana-design (Team:Kibana-Design)

[mattkime]

@mdefazio

Are we able to determine when a Data view was updated in another space?

We're not able to show which space made the last modifications. We can get a last modified date.

Are we able to show which spaces the data view is available in?
Assuming the user has access to the other spaces, can we show that space badge? If the user does not have access, do we add +X indicating it is at least in other spaces?

@jportner Do we show the full set of spaces where an object is available or do we only show the ones a user has access to?

How can we improve the potential for duplicate titles when sharing to other spaces?

This is true, but it seems true of all shared saved objects, therefore it seems to me it should be solved at the api level. Seems to me that all visualizations - or anything else named - would face this as well.

[jportner]

We're not able to show which space made the last modifications. We can get a last modified date.

We have an open ER to track usage data in saved objects: #81130
I added an example to that issue just now: "A history of when an object was modified, who modified it, and what space they modified it from"

@jportner Do we show the full set of spaces where an object is available or do we only show the ones a user has access to?

We only show the ones the user has access to. If there are additional spaces, the API returns '?' for each unknown space, and we render the count of unknown spaces in the badge. Here's a gif from when the SpacesList component was added in #89344:

This is true, but it seems true of all shared saved objects, therefore it seems to me it should be solved at the api level. Seems to me that all visualizations - or anything else named - would face this as well.

Agreed, most/all saved object types already face an ambiguity problem, and it's probably going to happen more often with sharing. We can attempt to solve this before the problem occurs (e.g., during the import/copy/share step), but I know that we had concerns about overloading these UIs which already have a lot of complexity.

At the very least, I think that we need 1. some way for consumers to tell Core if two different objects are similar, and 2. we need some way for consumers to find other objects that are similar to this one. We could attempt to solve this in a very coarse way by allowing consumers to specify a comparison field during type registration.

[mdefazio]

Version 1 updates

• Data view table updates
• Delete confirmation modal for bulk and single delete (from table and data view itself)
• Assign (Share) to spaces flyout

Outlined the changes below, please let me know if I missed something. I went off the screenshots you provided in the issue, so there could be some scenarios I'm not accounting for.

cc/ @mattkime

---

Data View table updates

I've included our updates from the data view title work here as well. Not many edits (I don't think) from what you have now—mimics the saved object table / spaces pattern joe shared above.

---

Delete confirmations

As mentioned, these were perhaps a bit sparse on copy and warnings. Again, pulling from the saved object pattern. These should be reviewed by a copy writer though.

Note that i'm also including the title + index pattern. I think it would be good for us to clearly outline the best way forward for these two attributes in regards to the UI. Is the Data view title enough? Should we only include the index pattern when viewing the data view detail page? If so, I'm fine removing these from the UI.

---

Share to spaces flyout

A few tweaks on this one, and again pulling from the saved object pattern. I've removed the button group in favor of a Select all / Clear option atop the selectable list.

[mdefazio]

Updated space selector flyout mockup to include search

[mattkime]

@mdefazio I'm looking at #123991 and determining what needs to be in that PR.

The data view management list - I'd prefer to just address the spaces column in that PR. The rest could happen when data views get proper names.

The changes to the share to space modal would be handled by @jportner and company as they own the component. We should verify there's nothing we're overlooking in regards to previous decisions.

I can definitely make the delete modal confirm changes.

Do we want to make any changes to the data view detail page? Do we want to show the used spaces?

---

I think we might need to extend the spaces list - You can't both limit the length of the list AND use the list as a click target - the # more text will expand the list AND open the flyout. @jportner thoughts?

[mdefazio]

The data view management list - I'd prefer to just address the spaces column in that PR. The rest could happen when data views get proper names.

Makes sense—however you all want to segment it works for me.

The changes to the share to space modal would be handled by @jportner and company as they own the component.

Absolutely. I'll connect with him to revisit the past discussions.

Do we want to make any changes to the data view detail page? Do we want to show the used spaces?

I'm not sure on this one. I don't know that we have any existing patterns for this (displaying spaces on a detail page), but not to say we shouldn't explore it. I'll discuss with the team and get back to you.

I think we might need to extend the spaces list...

I'll revisit this as well to see how we can improve.

[mattkime]

@gchaps Curious if we could get your thoughts about the language in the delete modals above.

[gchaps]

I think the warning message is a little repetitive and should be reduced to one line:

Bulk delete from table

1-line warning
Data views are deleted from every space they are shared in.

Text above table
You'll permanently delete 7 data views.
or
You're about to delete 7 data views.

Single delete from table

1-line warning
Data views are deleted from every space they are shared in.

Text above table
You'll permanently delete 1 data view.
or
You're about to delete 1 data view.

Delete from within data view

Can you remove the warning and use this text instead?

When you delete "kibana sample data", you remove it from every space it is shared in. You can't undo this action.

Share to spaces flyout

Allow more spaces to view and edit the data view. (include ending period)

[mdefazio]

I've updated the issue description with mockups and the new copy edits. (Thanks @gchaps !)

[mdefazio]

@mattkime Digging into this more.

You can't both limit the length of the list AND use the list as a click target - the # more text will expand the list AND open the flyout.

Perhaps I'm misunderstanding, but it seems that based on our sharing objects flow, clicking + X more will simply show all spaces in the cell. I was imagining that to trigger the share flyout, this would occur either from the row action menu, or from the bulk select menu.

Do we need to do it another way?

[jportner]

@mattkime Digging into this more.

You can't both limit the length of the list AND use the list as a click target - the # more text will expand the list AND open the flyout.

Perhaps I'm misunderstanding, but it seems that based on our sharing objects flow, clicking + X more will simply show all spaces in the cell. I was imagining that to trigger the share flyout, this would occur either from the row action menu, or from the bulk select menu.

Do we need to do it another way?

I chatted with Matt just now --

Technically the Spaces List won't let you do this today but it could be changed and I think it's a great idea.

Delete confirmations

As mentioned, these were perhaps a bit sparse on copy and warnings. Again, pulling from the saved object pattern. ...

These are great, I'm only a little iffy about the "Number of spaces" column. How would we render an object that has been shared to * All spaces? I guess we could just put the total number of spaces in that case?

Share to spaces flyout

A few tweaks on this one, and again pulling from the saved object pattern. I've removed the button group in favor of a Select all / Clear option atop the selectable list.

Yeah, I am in favor of simplifying this in any way we can, but I don't think we can get rid of the button groups like this. Selecting all spaces explicitly is not the same thing as sharing to * All spaces (which includes all current spaces and all future spaces, and requires "admin" privileges to do so).

One thing we could consider is adding a separate option next to the "Select All"?

Select All | Global | Clear
and then if you pick "Global", the individual spaces below would be checked / disabled. WDYT?

Might get crowded but it could be interesting to see how it looks.

[mdefazio]

Selecting all spaces explicitly is not the same thing as sharing to * All spaces

Good point. Thanks for bringing this up. What if we provide this as an additional checkbox: Include for new spaces? This gives the option to:

1. Treat this more like a role feature like you mention rather than a UI component option (that we can more easily hide/show)
2. Gives us some more room to explain what this would do
3. Provides the ability to select some and then also future spaces, or only future spaces --> Guessing this would be valuable, but not sure if there are technical limitations here.

[jportner]

I like the checkbox idea too, but (3) isn't technically feasible. In a nutshell, * always means all current and future spaces, we don't have a way to exclude spaces from that (and we have no plans or appetite to add support for that)
So if we did go with a checkbox, we'd have to disable the individual space controls beneath it.

[mdefazio]

@jportner @mattkime I went back and forth on having a switch, but in the end I'm not certain it is clearer without doing some user testing. So without dragging this out further, we can keep the current button group above the space selector that Matt had previously.

(I'm showing the space selector disabled when switching to All spaces—but if it hides it currently that's alright as well)

And the data view management page (I believe the only change here is the tooltip on the asterisk).

[mattkime]

@mdefazio Unfortunately I think adding the Last Modified is mostly useless right now and would require saved object migration to fix - discover tracks how frequently fields are used and this is saved to the data view. This blurs the line between purposeful changes and application state. The definition of a data view might not change for a long time but someone could be adding (or removing) fields in the discover view and the last modified date would indicate that usage.

[mdefazio]

@mattkime Makes sense. I updated the comment with the most recent version of the design (without the Last modified date)

[jportner]

@mdefazio all looks great!

[mdefazio]

Closed with #127557