[DISCUSS] Consistent saving/loading/listing

flash1293 commented 5 years ago

Topic

Various apps in Kibana how slightly different ways of how you interact with saved objects - how they are listed, how to save them, how to deal with dirty state, ...). In in ideal world saving and loading should work the same everywhere to make it easier for users already familiar with another part of Kibana. However this is not always possible due to different constraints and requirements.

This issue is meant to be a place to discuss the various ways of how this can be done, how we want to do it and document where it's OK to make exceptions.

Current state

Discover

Listing: No dedicated listing page, flyout in app with Open button in menu
Save: Save button in menu, always clickable (even when no changes were made)
New: New button in menu, always clickable
Data loss: New button and breadcrumb navigation always works, even with unsaved changes

Visualize

Listing: Dedicated listing page, no Open button in menu
Save: Save button in menu, always clickable (even when no changes were made) - @timroes I'm pretty sure there was a check for that, did this feature break / was removed?
New: No new button in menu, big prompt on listing page
Data loss: Breadcrumb navigation always works, even with unsaved changes

Dashboard

Listing: Dedicated listing page, no Open button in menu
Save: Dedicated Edit mode, Save button only visible when editing, always clickable (even when no changes were made)
New: No new button in menu, big prompt on listing page
Data loss: Breadcrumb navigation always works, even with unsaved changes

Canvas

Listing: Dedicated listing page, no Open button in menu
Save: Auto save
New: No new button in menu, big prompt on listing page
Data loss: No data loss due to auto save

Maps

Listing: Dedicated listing page, no Open button in menu
Save: Save button in menu, always clickable (even when no changes were made)
New: No new button in menu, big prompt on listing page
Data loss: Shows browser prompt when navigating away through breadcrumb

Lens

Listing: Uses Visualize listing page, no Open button in menu
Save: Save button in menu, only clickable if current state is dirty
New: No new button in menu, big prompt on listing page
Data loss: Navigation always works, even with unsaved changes

Graph

tbd - this issue is also meant to determine what's the right thing to do for Graph

Open questions

Do we need a New menu option? This is a shortcut for getting back to the listing and clicking the big button there.
Most of the things are already handled pretty consistent - should we follow this scheme for new apps / refactorings (like Lens and Graph) or move to another model in general?
Should we warn if the user is navigating away from unsaved work (e.g. back to the listing page)? Is this only important if it's not possible to go back?

cc @timroes

timroes commented 5 years ago

We discussed this quickly yesterday and we def want to align these. @elastic/kibana-design We would appreciate some feedback and help here, aligning those for a better UX.

Would you prefer me setting up some meeting to sync about that, or is the information in this issue satisfying and you could provide your ideas and feedback here?

snide commented 5 years ago

We're constantly having discussions around this stuff, as often as yesterday :)

We're trying to introduce a new control bar component https://github.com/elastic/eui/pull/2204 to handle some of these things, which will give us a generic way to deal with page level actions and saving. Specifically our biggest concern is around the "save" action being a little lost. @cchaos is going to do some experiments in Lens first and see how it holds up.

Preferably, I think we just need to provide some documented guidelines for the header section and the controls so that the individual teams can follow some dos and donts. I don't think a meeting is needed, we just need to produce that stuff and put them in EUI.

cc @hbharding and @katrin-freihofner since this is tangentially related to some of their work around consistent headers as well.

I'll put a reminder on design's next weekly so we follow through.

cchaos commented 5 years ago

Originally I was going to try out the control bar with save/dirty actions at the bottom of the page of Lens but it didn't make it into the 7.5 beta. We could still try for 7.6 to implement it in Lens first to get some initial feedback on the idea.

ryankeairns commented 5 years ago

+1 an example would be helpful. It's a little further off, but I think we're heading this direction with the Dashboard flow changes too (e.g. go to Lens from Dashboard; use control bar to 'Save & return' to Dashboard).

hbharding commented 5 years ago

@cchaos I really liked the stuff you showed us for Lens. The control bar could create a dedicated space for common actions like "load", "save", etc. and free up a lot of space near the query bar, which can feel overcrowded in some of the kibana apps.

I just noticed I was mentioned on this thread ~30 days ago. oops! Here's a screenshot of a concept for a new dashboard page, where I placed all "actions" in the top right. Link to prototype: https://www.figma.com/proto/EVApew6rgCqA8SNTBsbcJQ/Obs-Dev-150-Consistent-Header?node-id=200%3A2994&viewport=742%2C300%2C0.05039191618561745&scaling=scale-down

elastic / kibana