Introduce view and edit modes for Dashboards

[stacey-gammon]

What
Create two separate modes in dashboard, "View" and "Edit", so we can optimize the user experience around each.

The modes are temporary. They are a part of a user session, not a persistent property on the dashboard.

Why

• We believe the default, majority use case is consumption. Most of the time users want to view, not edit, their dashboards.
• There also exist use cases where the dashboard creator and viewer are separate individuals. By defaulting into a View only mode, we can prevent showing unnecessary controls to viewers, reducing the likelyhood they will accidentally break or change something.
• Improved UX/UI for the 'view only' use case:
  • No distracting border showing on mouse-over if the user just wants to drill in to a specific time on a dashboard
    Compare:
    
    
  • Prevent accidentally deleting panels from stray clicks.
  • Hide irrelevant controls and navigations menu items, making the dashboard easier to understand at a glance.
• Using limited navigation menu items in each mode allows us to add more menu items without that top nav bar getting too busy or crowded.
• A poor man's implementation of Supporting "locking" of dashboards, making them read-only #2683. Will not be sufficient for everyone, and we'll have to make it clear we are not offering true security, but may offer a halfway decent workaround for some use cases (as noted by some in that issue).

Future benefits

• Paves the way for an object level security workflow. In that situation, users without appropriate permissions would be able to view, but would not have an edit button available, and hence be in view mode only.
• Paves the way for a potential auto save feature. An explicit edit mode would greatly decrease the chance the wrong user would accidentally update a dashboard, if their intention was to view only.

What this is not
This feature and discussion is separate from optimizing the user experience around embedded or full screen mode. That feature will require further thought, but at a high level, we'll likely expose options during the share and link creation process so embedded links can be customized (e.g. show search bar, show timepicker, allow resize and move).

References

• Excerpts from https://discuss.elastic.co/t/kibana-5-0-step-back/66019/7:
  • " It's also pretty annoying / distracting to see the dotted borders around each visualization upon doing a mouse over giving the appearance of the dashboards being in development / edit mode rather than something presented as an end deliverable."
  • "Feel the same way, the dotted borders are kinda annoying. And I don't understand the removal of the olf borders either, makes it kinda harder to read the entier dashoard 😕"
• @uboness dashboard mockups
• Thor

Concerns

• @spalger expressed concerns around situations where the most common use case is editing a dashboard, and that this workflow would create an additional step. To get around this, I propose adding an edit button on the Open dialog so users can skip the default 'view mode' and go straight into 'edit mode'.
• @skearns64 expressed some concerns about this not being a true object level security fix. This is totally right - this is not object level security and we want to be clear that View Mode is a UI change only, and does not offer true protection. My hope is theEdit menu option at the top will make this clear.

Areas for Improvement and Next Steps

Filter conflicts

Filters are both stored with a dashboard, and used for exploration, and thus are editable in View Only Mode. We need to handle the situation where the user modifies a query/filter and/or time range in view mode, and subsequently hits Edit. We will give the option to Use current value or Load dashboard defaults. The message text depends on what has changed, so we can be specific

A slightly odd user experience can arise when the user adds a filter in view mode, selects Use current filters and immediately hits Stop editing. They will get the lose changes warning. I am hopeful this will be a small corner case as the user will probably do some other action once selecting Edit. In addition, we will include changes made to filters in the warning to make this case a bit more obvious as to what changed.

Save and Stop Editing Experience

Usability feedback confirmed that it feels odd to have Save and Stop Editing both available.

Next Steps - Few options on how to tackle this:

1. Move some of the save panel inputs to Options, make the title rename-able inline, and add one click save functionality. Then we can have two one-click options: Save and Cancel.
2. Have 'Save' always exit edit mode automatically and change Stop Editing to Cancel.

Potential for more duplicate dashboard names

The Unsaved changes dialog gives the user the option to save the dashboard immediately. If the dashboard is new, it will be saved with the default name of New Dashboard. I can see this increasing the number of duplicates.

Next Steps: Add new landing page table, track created by/creation date, and display in the table to expose more information and help users distinguish between objects with the same name.

Difficult to distinguish which mode the user is in - Edit or View

Next Steps - Add some UX to call out Edit mode, perhaps by changing some colors in title bar.

View only is the default mode

Some users may be primarily dashboard creators, and their default action is to edit a dashboard, not view it. For those users we have just introduced an extra click to start editing.

Next Steps
Once the dashboard landing page is added we can add an icon to jump directly into edit mode when a dashboard is opened, similar to how Thor does it.

PR for the POC.

[weltenwort]

As a vim user I am very much in favor of modal UIs. 😉 The way I have configured my vim is to have the status bar change color depending the current mode. The mode switching button itself might benefit from including the word "Mode" in its caption. And it could be set apart from the "new/open/save" controls in some way. Maybe visually grouping the controls into "always visible" and "mode-specific" controls is worth considering too.

[uboness]

This is a great feature to add that should have been in Kibana from day one. It has nothing to do with security, but with basic UX. We can't cover all use cases with UI/UX design, but we should cover the most typical ones and see what we can do to make Kibana usable for the others.

The meaning of "temporary" and "preview" is unclear to me. Feels like we're over complicating a simple view/edit functionality.

[uboness]

@weltenwort I agree that there needs to be a clear UI indication for the edit mode (no need for both, edit mode is enough IMO). We'll figure it out with the design team (note that the header is going to change soon, so eventually there'll be quite a few changes to how it is now in the PR)

[stacey-gammon]

@uboness By temporary, I mean they are not stored as part of the dashboard. There was some discussion in the design review about whether it should be an option under the options tab, and saved with the dashboard, but we decided it should be a per-user mode, not a dashboard setting, if that makes sense?

Preview was just another term for View mode. I originally had the button go from Edit to View Mode but it looked a little confusing with the mode suffix because one could wonder if it was a label showing that they were currently in View Mode or a button that would switch them into view mode. That can be changed, Preview is also not super clear as you pointed out.

[uboness]

By temporary, I mean they are not stored as part of the dashboard. There was some discussion in the design review about whether it should be an option under the options tab, and saved with the dashboard, but we decided it should be a per-user mode, not a dashboard setting, if that makes sense?

still not following... view/save should not be a dashboard specific feature, it should apply to all dashboards. we need to build consistency into Kibana.. not introduce new features to increase inconsistency. For this reason, I wouldn't even use the terms "user session" or "temporary".. this is confusing.

Preview was just another term for View mode. I originally had the button go from Edit to View Mode but it looked a little confusing with the mode suffix because one could wonder if it was a label showing that they were currently in View Mode or a button that would switch them into view mode. That can be changed, Preview is also not super clear as you pointed out.

from a high level functionality description, it's a edit vs view mode. But the UI doesn't need to explicitly use this two buttons. For example, if we decide that the "view mode" is the "main" mode, then you don't need a button for it. For example, when you enter the dashboard for the first time, you're in a "view" mode, but that implicit. You have an edit button that will enable you to edit the dashboard. Clicking on that button changes the view to an "edit" view. There, you have all the tools you need to edit the dashboard + two buttons: "Save" & "Save and continue editing". (an alternative would be "Save" & "Update", where "Update" = "Save and continue editing". When the user clicks the "Save" button, it shows back the "view" mode.

[stacey-gammon]

view/save should not be a dashboard specific feature, it should apply to all dashboards.

@uboness We are in agreement. I was being explicit because whether or not to do that was debated during the design review. The decision was up in the air at the end of the design review meeting and we ran out of time. Some of the participants re-convened later on, at which point we agreed on the above point (that it shouldn't be a dashboard specific feature).
I didn't mean to be confusing, but wanted to let original participants know the outcome of that second discussion, and give anyone a chance to pipe in if they disagreed.

[stacey-gammon]

@cjcenizal brought up some issues around the interaction between editing the search bar/time picker and filter bar in view vs edit modes.

Rationale
A user would not expect changes to the search bar to disappear when they click Edit. A user would not expect those changes to be saved, nor a lose changes warning, if they subsequently hit Stop editing without making further modification.

The following tables outline different scenarios and whether or not a you will lose changes warning should be shown. In the outlines scenarios below, the user left edit mode without manually saving their changes.

Search Bar

Initial	View Mode	Edit Mode	Warn?	Final	Reopen
original	original	original => changed	Yes	changed	original
original	original => changed	changed	No	changed	original
original	original => changed	changed => again	Yes	again	original

Explanation of the Mental Model
There are three states we are concerned about here:

1. Temporary Local State - Changes made in view mode
2. Persisted State - State that is saved in the database
3. Edited State - Changes made in edit mode.

The relationship between the three states and view modes:

1. View mode defaults to persisted state.
2. Changes made in view mode create a temporary local state.
3. Edit mode displays temporary local state as it's default.
4. Dirty flag is based on Edited State, and is not a comparison of Persisted State to Temporary Local State. Otherwise row 2 would cause a lose changes warning.

Confirming losing changes will revert to temporary local state. Saving persists temporary local state.

These two tables are included for completeness but essentially act the same as the search bar.

Time Picker
Only applies if Store time with dashboard is checked.

Initial	View Mode	Edit Mode	Warn?	Final	Reopen
T1	T1	T1 => T2	Yes	T2	T1
T1	T1 => T2	T2	No	T2	T1
T1	T1 => T2	T2 => T3	Yes	T3	T1

Filter Bar
The difference with filter bar is that you can't easily add filters within Edit mode, so you won't get a warning if you want to preserve a pinned filter to a dashboard. The user will just have to manually click Save to do so.

Initial	View Mode	Edit Mode	Warn?	Final	Reopen
F1 Pinned	F1 Pinned	F1 Pinned => F1 Pinned & F2	Yes	F1 Pinned & F2	F1 Pinned
F1 Pinned	F1 Pinned => F1 Pinned & F2	F1 Pinned & F2	No	F1 Pinned & F2	F1 Pinned
F1 Pinned	F1 Pinned => F1 Pinned & F2	F1 Pinned & F2 => F3	Yes	F3	F1 Pinned

[cjcenizal]

@stacey-gammon Not sure if this makes sense, but maybe we can further codify our thought process around state by classifying state into two buckets...

Document state
Properties directly associated with a saved object. This is the "thing" we're looking at.

Perspective state
Properties associated with the time picker, search bar, and filter bar. These are the "lenses" through which we view the "thing" we're looking at.

What we see in the UI is an aggregate of the document state and the perspective state.

[stacey-gammon]

++ Yea that sounds good. The only complicated part is that some state values exist in both perspective and document state. They overlap.

[stacey-gammon]

The decisions made from the last usability session:

• Get rid of filter conflict warning and always follow the Use current filters option.
• Combine Save and Done as both are confusing
  • I'd like to explore making this a next step, rather than a requirement prior to check in (see below).
• When there are unsaved changes, switch lose changes button to Exit without saving and do not refresh the dashboard to it's original, saved state.

@cjcenizal @uboness @alt74 I want to make sure we are on the same page with the desired behavior.

• If a user modifies the query, clicks Edit, makes no changes and hits Done, there will be an unsaved changes warning.
• If a user clicks Edit, deletes a visualization, hits Done and selects Exit without saving, then clicks Edit again and Done immediately, the warning will show up again.

Essentially, we will end up showing the unsaved changes warning based on the current state vs the saved dashboard state, whether or not those changes were made in Edit or View mode.

This was originally a cause of concern, hence the introduction of the Filter Warning and lose changes. I want to make sure I am understanding the decisions made and that we are all on the same page.

Additionally, I'd like to consider not implementing One Click Save prior to checking this in. I think that will open up an additional can of worms and further delay this feature. While it's awkward to have both Done and Save, I think the benefit of the feature outweighs this awkwardness, and that we can tackle combining them as a next step.

Please let me know your thoughts!

Also, for anyone wanting to experiment with the latest flow, I created a new PR/branch here: #10270

[alexfrancoeur]

@stacey-gammon This workflow seems much cleaner! I know this has been an on-going effort to finish this new view. As discussed earlier, the view / edit mode is a base for additional features in the future such as read-only mode for non-admin users and a cleaner dashboard experience in general. My feedback can be found below.

In response to your comments above

If a user modifies the query, clicks Edit, makes no changes and hits Done, there will be an unsaved changes warning.

As a user, if nothing is changed I would not expect to be prompted to save or exit without saving. This is a minor usability concern though.

Additionally, I'd like to consider not implementing One Click Save prior to checking this in. I think that will open up an additional can of worms and further delay this feature. While it's awkward to have both Done and Save, I think the benefit of the feature outweighs this awkwardness, and that we can tackle combining them as a next step.

In the recent customer conversations I've been in, there have been some very positive reactions to the concept of "dashboard only mode". At this point in the game, I agree that it might make sense to close this issue and iterate as users begin to utilize the new feature. However, I believe that done and save are far too similar. What are your thoughts on the following approach?

• Remove the done button
• Keep the save button in both view and edit mode where saving behavior is the same as it is today
• Introduce a one click cancel button in edit mode that is the equivalent of exit without saving

This splits the two modes while still giving our current user base some consistency as far as saving goes.

General feedback & wish list

• I think we're struggling here on what to do if a user want's to update the dashboard with a new query while in view/edit mode. If we were to add an update and clone button in view only, this should resolve all of these scenarios. Both of which can be conditionally removed when we introduce object level access control with read-only permissions.
  • update (or save) would update the existing dashboard
  • clone allows a user to use the current settings and save as a new dashboard
• I like the concept of a done button but it's far too similar to save at the moment. I'm pretty sure this has already been discussed in detail but in order to combine two, I continue to believe we will need to address the following
  • Add inline editing of a dashboard name as part of edit mode. This could default to "New dashboard" but can be adjusted before saving. This way we do not need a separate rename tab which can be a bit awkward for initially naming your dashboard
  • Introduce clone (as stated above) to replace the save as scenario during the save process
  • Push store time with dashboard to options
• When in edit mode it might be nice to have an empty [ + ] tile to add a visualization directly from the dashboard. This could possibly lead you to an interim list page where you can select and preview one or multiple visualizations

There's my brain dump, please reach out if you're interesting in exploring any of these ideas in further detail

[stacey-gammon]

Thanks for your feedback @alexfrancoeur!

I talked with @cjcenizal after posting the above and we decided to move forward with one click save as being a prerequisite, since as you also point out, Save and Done are too confusing. Hopefully I can get this done without too much iteration.

Add inline editing of a dashboard name as part of edit mode. This could default to "New dashboard" but can be adjusted before saving. This way we do not need a separate rename tab which can be a bit awkward for initially naming your dashboard

I believe this is a no go as the design team feels pretty strongly about not implementing the inline edit due to upcoming changing in the header. So for now, I think we'll have to stick with a slightly awkward rename panel.

When in edit mode it might be nice to have an empty [ + ] tile to add a visualization directly from the dashboard. This could possibly lead you to an interim list page where you can select and preview one or multiple visualizations

Great idea! But too much to tackle for this PR. :)

If we were to add an update and clone button in view only, this should resolve all of these scenarios. Both of which can be conditionally removed when we introduce object level access control with read-only permissions.
update (or save) would update the existing dashboard
clone allows a user to use the current settings and save as a new dashboard

I'm not a fan of this as we would be allowing editing and saving in view mode, and I think that creates a confusing UX.

I think I have enough to go on to make progress, so I will update this ticket once One Click Save is finished and we can re-explore this PR in the context of that world.

[alexfrancoeur]

@stacey-gammon
++ on the one-click save capability. Yes, the visualization workflow certainly wasn't an expectation for this PR just something to think about. I'll dig around and see what ER's and issues are open for adding a visualization. I also understand the UX concerns about save in both modes. I was only trying to think of a way to ship this out with minimal iterations. I guess we'll also have to view the "rename" tab as an interim solution :)

[uboness]

If a user modifies the query, clicks Edit, makes no changes and hits Done, there will be an unsaved changes warning.

there should be a warning... though terminology is important. In this scenario I'd rather get a message like "Would you like to store the current query/filter with the dashboard? [Store] [Do Not Store]"

If a user clicks Edit, deletes a visualization, hits Done and selects Exit without saving, then clicks Edit again and Done immediately, the warning will show up again.

this workflow is a bit off IMO... this is probably where we need to differentiate between queries/filters and visualizations:

• When the user changes the filter/query in Edit mode, then clicks done + exit without saving, then we would just move to View mode a leave the current filter/query as is (I believe this is what you've implemented now)

• When the user changes the visualisations in Edit mode, then clicks done + exit without saving, then we would restore the visualizations that are stored with the dashboard and show them in the View mode (effectively, the user will lose the changes they made to the visualizations).

Why?

queries and filters can be seen as navigation tools for data and are not typically associated with something that a dashboard should store. The best example for this is that it's possible to change them in View mode... I see queries & filters as auxiliary (or secondary) information that we offer to store with the dashboard.

Visualizations on the other hand, are the primary objects that are associated with the dashboard - they are highly coupled to the dashboard definition from the user perspective. Following the example above, there's a reason why in View mode we don't allow changing the visualizations (If we did, that would not really be a view mode would it?).

With the above in mind, it feels strange that we don't restore the visualizations after unsaved changes in dashboard... When I first looked at the current behaviour in the gif above, my first reactions was "wait... so was it saved for not?" cause I expected the viz's to be restored.

[stacey-gammon]

there should be a warning... though terminology is important. In this scenario I'd rather get a message like "Would you like to store the current query/filter with the dashboard? [Store] [Do Not Store]"

What if the user changes the query in view mode, then changes a visualization in edit mode? How do we combine the two messages into one? Or would we ask them both questions separately?

When the user changes the filter/query in Edit mode, then clicks done + exit without saving, then we would just move to View mode a leave the current filter/query as is (I believe this is what you've implemented now)

I did, but I reverted it back to 'lose changes' as it just felt more natural to me. I think we're overcomplicating it. IMO reverting everything is a clear, unambiguous experience. You select lose changes and the state reverts back to the last saved dashboard. There is no confusion over why part of the information stored with dashboards gets reverted, but other parts don't. We have thought over and over again about the subtle distinction between filters and visualizations, but to a user, this distinction is probably a bit vague. It also removes the need to handle complicated use cases like the one above.

Keep in mind that a user clicking Edit is most likely intending to edit something and save it to the dashboard. The use case of clicking Edit then Done immediately is not going to happen often in practice, nor do I expect lose changes to be a common selection.

Relevant notes from usability sessions seem to indicate that we could probably go either way, and there was no clear consensus on how it should act:
Session 1. Expected "lose changes" to revert edits made to the query and/or time picker.
Session 2. Wasn’t exactly sure what "losing changes" would do to the query but wasn’t surprised when it reverted to what was saved in the dashboard.
Session 3. Expected confirm losing changes to preserve current query and time initially but made more sense after adding a visualization. Perhaps renaming “Lose changes” to “Restore defaults”
Session 4. Expected lose changes to revert state to what existed prior to clicking "edit".

In any case we do modify the Save message so it calls out changes made to query/timepicker/filters.

The new view edit mode complete with one click save is ready for a test round. I ended up just incorporating one click save directly into the view/edit PR since it ended up being easy to implement and just felt like a better flow with View/Edit.

I think the best way forward is for every one to get hands on with the PR and see if it feels unnatural in practice.

[uboness]

I can't follow any of these gifs... they're too fast (can't read the dialogs)

[uboness]

I did, but I reverted it back to 'lose changes' as it just felt more natural to me. I think we're overcomplicating it. IMO reverting everything is a clear, unambiguous experience. You select lose changes and the state reverts back to the last saved dashboard. There is no confusion over why part of the information stored with dashboards gets reverted, but other parts don't. We have thought over and over again about the subtle distinction between filters and visualizations, but to a user, this distinction is probably a bit vague. It also removes the need to handle complicated use cases like the one above.

at the end of the day, it's not about what we want to user to expect, but what users expects as they're playing around with the UI. Here's something to think about - for you as a developer, it's obvious that the query is stored with the dashboard, for an objective user it might not (probably not). Now, whether we want to target objective users or not, it's a different question (objective user for me is someone that doesn't know kibana and doesn't know the behaviour of prev. Kibana versions).

I can tell you on my side with high certainty - If I change the query (because I'm toying with data... and that's what I do with kibana - toy with data, queries and filters), and I just spent time to build the exact filter/query that I wanted, then I click edit, change some visualizations just to realise I actually didn't want to, then when exiting edit mode without saving, everything I worked on so far just disappears and replaced by kibana - I would be very annoyed.

Does it complicates things? maybe.... I'm still an annoyed user.

I want to be clear here - to me, the fact that the queries/filter were always stored with the dashboard was never obvious. The fact that the visualizations where always stored with the dashboard was always obvious. I would expect others to feel the same about this.... maybe I'm wrong here... don't know. But if I'm right, then there's by definition clear distinction between queries/filters and visualisation and we need to serve the most common expectations around these. I don't expect us to serve everyone with a single solution, but I do expect us to serve the most common expectations users have - not because it's simple for us, but because it's simple to explain it as the most common expectation. Regardless, we should always be able to provide a "path" for those that the behaviour we define doesn't fit the way they see dashboards.

I'll leave it to others ("real" users of the dashboard, which are not necessarily Kibana's devs) to express what they expect or not from this behaviour.

[stacey-gammon]

The more I'm playing with the latest iteration the more I dislike only having a done button. I think users will be confused, even though it's pink. I think users will be nervous to click it for fear of losing their changes. I chatted briefly with @alt74 today and he felt similarly.

Perhaps the only reason why people hated Done and Save so much was due to Styling (the pink) and naming. We initially gave it new styling because it wasn't very clear which mode you are in. This is clearer in the latest iterations, even without the pink button, due to the dotted borders and controls always being on, as well as the difference in the number of top nav options.

I think we should still have Save (can still be a one click save, one that even bounces the user back to view mode), and we should also let them exit without saving. The naming of this button is the tough part:

View
Exit
Close
Exit Edit Mode
Stop Editing
Cancel
??

In all of the usability sessions, no one walking through a general task hit this 'Done/View/Exit' button. If you are an editor, you are editing and opening dashboards. You probably don't care about view mode. The edit/save flow for the UX tasks was always: hit save, then go to the landing page to open another dashboard. The only time they clicked Done was if I specifically asked them to.

I think we should revisit this decision. In the meantime, I'm creating an iteration #4: #10446

@uboness

and I just spent time to build the exact filter/query that I wanted, then I click edit, change some visualizations just to realise I actually didn't want to, then when exiting edit mode without saving, everything I worked on so far just disappears and replaced by kibana - I would be very annoyed.

Agree this is a risk, though I think this is a problem that could be solved separately. For instance, if queries take such a long time to create, maybe we should be saving them as objects that can be retrievable?

As far as what happens to the filter after lose changes, I understand your thoughts and concerns, but unless you feel strongly that we should keep the filter around, I'd like to explore more usability sessions sticking with lose changes reverting the dashboard to the last saved state. Chatted briefly about this with @alt74 as well and he seemed on board with this flow as well.

cc @alexfrancoeur @tbragin @cjcenizal

[uboness]

Re: buttons. I've expressed my dislike to the "Done" button before. I think it introducing something completely new to the user that is hard to digest and very much confuses (my first reaction was "What's Done?"). Why don't we treat the same as anything else that we're editing - it can have two buttons: "Save" and "Cancel".

Agree this is a risk, though I think this is a problem that could be solved separately. For instance, if queries take such a long time to create, maybe we should be saving them as objects that can be retrievable?

yes, that can definitely be a direction (I believe that's what @markharwood suggested)... but today we don't have it and it'll take time to have those as well.

[uboness]

You probably don't care about view mode. The edit/save flow for the UX tasks was always: hit save, then go to the landing page to open another dashboard. The only time they clicked Done was if I specifically asked them to.

this is a false assumption IMO. As an editor of many systems, I always alway always want to look at the view mode after I've edited something. You want to make sure that the view mode user will get exactly what you want them to get and thus you try it out all the time. Also, most "editors" are also view mode users. Editing the dashboard is definitely not their main job.

[alexfrancoeur]

I agree with @uboness on this last comment. Even editors want to review their final product. I like the workflow of saving and automatically exiting edit mode, it works for me. It's actually a similar concept to "Done" in a system that doesn't allow you to revert your changes. This seems like a good compromise to me. I also agree that adding the "Done" button is too drastic of a change.

The only snag I noticed in the workflow was clicking exit. I didn't expect to be prompted with a save or revert changes dialog. I expected to simply exit edit mode and go back to view mode without saving my changes. This is just my personal preference though. I'm interested in hearing others thoughts on this but agree that it's time for another quick round of usability tests with those further away from this. I'll schedule some quick sessions for next week.

[uboness]

@alexfrancoeur if we call it "Exit" we need this dialog for sure, I think it's starting to be debatable if name it "Cancel" (as canceling has a much stronger intention attached to it wrt the changes made). That said, Personally, even with a "Cancel" button, I'd still prefer having the prompt.

I'd love for the button to be called "Cancel" anyhow (instead of "Exit") + give it a subtle red background (like cancel buttons typically have). Having "Exit" menu item doesn't sit well with me. If you're editing a User, do you show an option to "exit" or to "cancel"? When you're editing a watch, do you "exit" or "cancel"?

[uboness]

Also... I'd like to suggest another option, which I'm not sure if it was covered at any point, and if it was discussed at some point and I missed it (or I don't remember), apologies.

What if this is truly a "View" and "Edit" mode. In the sense that in the view mode, everything is locked in place and cannot be changed, and in the "Edit" mode you have full freedom to apply any changes. Switching between the mode doesn't do anything but enabling/disabling the user to edit/modify the dashboard.

What does this mean - no need for confirmation dialogs anymore... if the user changes things in edit mode, they're immediately applied. changing to view mode will just lock the current state of the screen and will no longer allow editing.

I think this can greatly simplify things for us and the users. I do think however that we'll need to provide one more feature to make this possible - history. At least limited history of modifications, such that the users can undo (up to a certain point) changes they did.

This is essentially very similar to how Google docs works for example.. just something to think about. We might be approaching it from the wrong place...

[stacey-gammon]

I would love to have auto save, but agree undo and history is a prereq, and probably a long way off. I see that being a longer term goal.

[alexfrancoeur]

@stacey-gammon @uboness dialog aside, I think renaming to Cancel might be good anyway. As a user you have entered edit mode and can either save your changes or hit cancel to revert.

I prefer the workflow without the dialog box for the very reason mentioned in Uri's second comment. I am used to (and clearly like) the dynamic of automatically saving changes made within edit mode. This is how a lot of dashboarding view/edit modes are handled and was also the approach we took with my previous product. I demoed this to Stacey already but would be happy to share an example with anyone interested.

If we're in agreement for autosave as a future item I can open an issue for tracking purposes.

[cjcenizal]

@alexfrancoeur Great idea! Would you mind creating that autosave issue? And could you cross-reference the undo/redo issue (#8887), this request a user made for the ability to autosave Dashboards (#6401), and this issue for surfacing some indication of saved/unsaved state (#8886).

[uboness]

History / undo / redo !=. Auto save

There are different ways to implement this. But lets first focus on getting this feature (view/edit) out of the door.

[alexfrancoeur]

I agree with @uboness on this one, history with undo/redo is not necessarily the same as auto-save. That to me is a bit of an augmentation (and maybe a future step). I think it might make sense to discuss when we're all together in a few weeks. Once we've decided on some next steps, I'll go ahead an open an issue.

@stacey-gammon I'd be interested in your thoughts about the button nomenclature that Uri proposed

[stacey-gammon]

@alexfrancoeur Cancel sgtm, made the changes to the PR.

[stacey-gammon]

After the last usability session with @alexfrancoeur, I have concerns about the one click save/rename functionality:

• People will miss naming their dashboards the first time around. It's called rename not name.
• It won't flow well with the new warn on duplicate name functionality. We don't save the new name until the user hits Save so the warning would only pop up then. Tf they got the duplicate name warning, they'd have to go back into rename. This feels awkward.

I have yet another proposal:

• Go back to the old save panel
• Keep the new functionality that Save bumps you automatically into View mode. This means we can keep the two current button names that seem to be working well: Save and Cancel. The biggest reason we decided One click save should be implemented first was to get rid of the too similar buttons: Done and Save.

Funny enough, we are slowly working back to the very first iteration of this feature, just with different names for the new top nav button.

Benefits of this approach:

• Less temporary UI changes (here's a new rename panel that will go away soon anyhow).
• More consistency with other apps (people are used to the save flow of visualize/discover).

And yes, I have yet another (believe it or not) iteration #5!

The gif has a different order of top nav buttons - the first one is in the PR. If Cancel is in the same place as Edit, and you click it twice by mistake, you get right back into view mode. This can make it seem like clicking the button did nothing, so I wanted to move Cancel.

[cjcenizal]

For reference, here are a few other UIs which surface Save and Cancel buttons. I think we're on the right track by leveraging this common pattern.

[xycloud]

cannot be agree with more, awesome