-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Introduce view and edit modes for Dashboards #9431
Comments
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. |
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. |
@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) |
@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.
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 |
@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). |
@cjcenizal brought up some issues around the interaction between editing the search bar/time picker and filter bar in view vs edit modes. Rationale The following tables outline different scenarios and whether or not a Search Bar
Explanation of the Mental Model
The relationship between the three states and view modes:
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
Filter Bar
|
@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 Perspective state What we see in the UI is an aggregate of the document state and the perspective state. |
++ Yea that sounds good. The only complicated part is that some state values exist in both perspective and document state. They overlap. |
The decisions made from the last usability session:
@cjcenizal @uboness @alt74 I want to make sure we are on the same page with the desired behavior.
Essentially, we will end up showing the This was originally a cause of concern, hence the introduction of the Filter Warning and 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 Please let me know your thoughts! Also, for anyone wanting to experiment with the latest flow, I created a new PR/branch here: #10270 |
@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
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.
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
This splits the two modes while still giving our current user base some consistency as far as saving goes. General feedback & wish list
There's my brain dump, please reach out if you're interesting in exploring any of these ideas in further detail |
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,
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.
Great idea! But too much to tackle for this PR. :)
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. |
@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]"
this workflow is a bit off IMO... this is probably where we need to differentiate between queries/filters and 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 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 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. |
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?
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 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: 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. |
I can't follow any of these gifs... they're too fast (can't read the dialogs) |
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. |
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 I think we should still have View 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 I think we should revisit this decision. In the meantime, I'm creating an iteration #4: #10446
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 |
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".
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. |
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. |
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. |
@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"? |
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... |
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. |
@stacey-gammon @uboness dialog aside, I think renaming to 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. |
@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). |
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. |
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 |
@alexfrancoeur |
After the last usability session with @alexfrancoeur, I have concerns about the one click save/rename functionality:
I have yet another proposal:
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:
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 |
cannot be agree with more, awesome |
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
Compare:
Future benefits
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
Concerns
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 hitsEdit
. We will give the option toUse current value
orLoad dashboard defaults
. The message text depends on what has changed, so we can be specificA slightly odd user experience can arise when the user adds a filter in view mode, selects
Use current filters
and immediately hitsStop editing
. They will get thelose changes
warning. I am hopeful this will be a small corner case as the user will probably do some other action once selectingEdit
. 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
andStop Editing
both available.Next Steps - Few options on how to tackle this:
Save
andCancel
.Stop Editing
toCancel
.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 ofNew 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.
The text was updated successfully, but these errors were encountered: