Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

View/edit mode for dashboards #9508

Closed
wants to merge 23 commits into from

Conversation

stacey-gammon
Copy link
Contributor

@stacey-gammon stacey-gammon commented Dec 15, 2016

Implementation of #9431

@epixa
Copy link
Contributor

epixa commented Dec 26, 2016

Looks like the build failed on this one

@stacey-gammon
Copy link
Contributor Author

jenkins test this

@stacey-gammon stacey-gammon force-pushed the view-edit-mode branch 2 times, most recently from 0d59125 to d080e3e Compare December 28, 2016 15:30
@epixa epixa changed the title View edit mode View/edit mode for dashboards Dec 28, 2016
Copy link
Contributor

@kobelb kobelb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome, I really like it.

My only concern is that while editing a dashboard, the user can click the 'Stop Editing' button without saving their changes. I could see a user hit 'Stop Editing' as opposed to 'Save' and assuming the changes that they made were saved, because it kinda looks like it.


function getViewConfig(modeChange) {
return createTopNavExecuteConfig(
'Stop Editing',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nitpick, the 'key' for this config doesn't match the others.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because of the case? I did that on purpose because I want the second word capitalized. The first word gets auto capitalized but the second doesn't. I could do stop editing and it'll show up as Stop editing but I didn't like that. I could do stop Editing but that's weird too. I suppose I could also find where these words are capitalized and capitalize every word there, but that might affect other tabs. I'll revert to stop editing to be consistent here and we can decide on the casing later, and change it for all or nothing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, please disregard this entirely. I made this comment a while ago, and it's no longer valid.

@stacey-gammon
Copy link
Contributor Author

Hmm, that's a really good observation. I see two ways to fix this.

  1. Add a warning if unsaved changes are detected. I think this will be trivial to implement as I heard there is already a dirty flag, but I haven't confirmed yet.
    or
  2. We make Stop Editing auto save. My concern with this is if the person doesn't want to save their changes. Although they do have a way around this - by refreshing the page - but it's not super clear that Stop Editing will save the dash.

I think in most cases #2 would be a better UX, but #1 is safer.

Thoughts? Any input on this @cjcenizal?

@kobelb
Copy link
Contributor

kobelb commented Jan 2, 2017

Part of me wonders whether having a single 'Save/Cancel Editing' button that changes based on the appState.isDirty would be sufficient.

@kobelb
Copy link
Contributor

kobelb commented Jan 2, 2017

On second thought, maybe always having a 'Save' and 'Cancel Editing' button would be better than my previous suggestion, and disable the Save button before there are changes. I liked your idea about showing the user when there are unsaved changes as well, but I dunno if my idea about disabling the 'Save' button would be clear enough.

@epixa
Copy link
Contributor

epixa commented Jan 2, 2017

How about a toaster message (not red) when they switch to view mode with unsaved changes? Without better test coverage (both unit and integration) around the dirty flag, we probably should not be disabling the save capability on it. We've had issues already with it not being entirely reliable with reporting in x-pack.

stacey-gammon and others added 13 commits January 19, 2017 10:20
and implement new angular style suggestions from Joe
no point making vanilla code that's really only going to work with angular i guess...

also broke apart the confirm modal from the injector, and made safeConfirm just use the confirm modal
 - Move safe_confirm into modals folder
 - make data-test-subj camelCase.
 - get rid of $timeout call, doesn’t seem necessary anymore, now that
window.confirm is not being used.
and fix some bugs
NOTE: code is a mess. Once UX is nailed down I’ll clean it up.
@stacey-gammon
Copy link
Contributor Author

stacey-gammon commented Jan 19, 2017

Things required before this PR can move forward:

  • Dashboard landing page. PR
  • Breadcrumbs - In landing page PR
  • Removal of Open and New nav options (same PR above)
  • Switch Stop Editing to Done
  • Outlines always on in edit mode.
  • Stay in edit mode if navigating in kibana (store mode in state).
  • Stylize Done to call it out.
  • Clean up code

Maybe required:

  • Better distinguishing between objects with duplicate names

Figure out later:

  • Navigating away with unsaved changes (an existing problem)
  • Get rid of save panel - move to options/rename/duplicate.

Still TODO:
 - Add clickable breadcrumbs
 - Remove New and Open top nav options
improve tests
- Add new landing page empty text (merge)
- Make view mode stateful
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Dashboard Dashboard related features review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants