Make Visualize Editor "Play" and "Reset" buttons more apparent. #11094
Conversation
cjcenizal
added
Team:Platform-Design
|
To-do
|
|
It will be nice if buttons are at the top of page or keyboard shortcuts (Ctrl+Enter for run and Ctrl+R for reset). |
|
Hey @Prazzy is the problem that the buttons are too far away from the form for you? Are you using a large monitor, so the buttons are way down below now? In terms of keyboard shortcuts, you can hit "Enter" if the form has focus, to re-run the visualization. A keyboard shortcut for resetting is a great idea. Thanks for the feedback! |
|
@cjcenizal When you have a lot of metrics and few buckets including sub-buckets and few of them are expanded, then it's hard to scroll down to reach these buttons. Also, it would be nice to add expand/collapse all for metric and buckets (like in gmail |
|
Ahhh I see. Then you will be happy to know that the buttons will never be hidden off-screen. They'll just stick to the bottom of the screen no matter how many metrics and buckets you have:
Expand/collapse-all is another great idea! |
|
I couldn't find the buttons when I looked at these screenshots. I literally stared at the screen looking for them and thought I was going crazy. I had to read the issue description to see they were at the bottom. I can't explain why I had this much trouble finding them, but it does make me really concerned that putting them at the bottom of the screen is going to make them hard to find for others. |
|
@epixa I can empathize. There's a big visual disconnect between the form and these buttons if you have a taller screen, and if you haven't filled up the side bar with a configuration it can be hard to find those buttons. I wonder how other people will react to them. An alternative solution is to place the buttons closer to the configuration controls, and stick to the bottom only once the configuration pushes them down there.
|
|
At a glance, I like that option far better. I'm just looking at the screenshots though, so that's no replacement for actually playing around with it. |
|
I totally with @epixa here... I think that I naturally looked for those to be somewhere at the top |
|
the first option (to have buttons at the bottom) looks pretty to me. I agree they may look a bit disconnected on the big screen, but i dont find this to be a show stopper. But its not something we just invented, its something that ppl are getting more and more used to i think from the mobile experience (and google material design ...) its quite common to expect your button to be floating on the bottom. (tons of apps like outlook, intercom and so on do it since ever) So for me personally there was a bit of a "where is my button" moment. But I can blame that mostly on my previous experience with kibana and expecting the button to be where i am seeing it normally. If this would be my first kibana experience .... hard to say .... but i would definetelly not be looking for the button where we have it now (i do remember that with my first kibana experience the current button was not the most obvious) the second option, to have buttons right under the form .... well probably easier to find (but what happens when the form is longer the screen ? we DO float them then ? ) but i do not like it visually nearly closely as much, so i would say that if we don t like buttons at the bottom, then lets keep exploring. |
|
While I had agreed with the initial concept, I immediately had a similar "where are my buttons" moment that everyone else seems to have had. On a big screen, they do look a bit disconnected. The second approach works much better in this fashion. I agree that we should continue to explore. If it's helpful CJ, I can recruit some "non-Kibana users" internally / externally to see how they react initially. I agree with @ppisljar that this experience is much more common these days but it might be worth introducing with a larger design overhaul instead (if we don't introduce real-time updates). We need to find a balance of this being a drastic change for existing users vs. improving the experience for new users. The answer could simply be emphasizing the current submit button a bit more and including the "run" text. |
|
Can we also explore the option of not having a play button at all? I was never a fan of this button to begin with... why can't we just update the chart "live" as we change the options (this is what I'd expect as a new and experienced user). As for the location of the buttons... with their current location it depends on the screen size and on the amount of content in the options panel. The minute there's a "depends" here... we have a problem. Perhaps one aspect of the problem is that it's not "popping out" as currently it's styled as any other primary button on the screen (so it's hard to distinguish it from other primary controls in the options panel). Maybe we need to change its color to green? |
|
I'm also all in for the "live chart". I don't have the history behind the reason for choosing to submit changes but I get the feeling it wasn't because of user experience. I assume that there could be performance issues for large data sets with multiple, fast changes. Regardless, I agree with Uri and would like to explore for future versions of the visual builder. |
|
One of my minor pain points with the new time series visualize is that it is live. It makes the UI feel really slow because I either have to stop and wait for an unspecified period of time to see the changes or I have to try and get as many changes in as fast as possible so that I don't have to wait for multiple extremely slow queries to go through. |
|
We'll have to explore live-updating later on. One of the problems with live-updating is that it's too easy to get into an error state with this current UI, so a lot of the user's changes wouldn't result in anything useful. Exploring live-updating will require broader UI and UX exploration. I think there are 2 principles we can agree on:
I can think of a couple ways to solve this problem with some limited design changes to the sidebar. Let me take a swing at it and then I'd like to take you up on your offer to pass it by some users @alexfrancoeur. |
|
Related is the search button - I've seen a lot of people press this after updating rather than Run and be confused why it didn't work. Also there is no obvious cue that the visualisation no longer matches the settings. How about something radical like grey out the entire viz when you change any settings and put a big reload button over the top? |
|
completely agree with @trevan on the slowlines of time series visual builder. even if query runs fast (below 1s) thats an annoying experience, the whole thing redrawing when im in the middle of changing options. so this would only really work with super fast queries and super simple charts (something that can be queried and rendered (whole round trip) in less than 100ms could maybe work. as CJ mentioned, another problem with visualize is that we have so many in-between-states which just cant render. imagine adding a new bucket ... until you selected a field we cant use it. so how do we communicate to the user, that we are redrawing all the time, but not this time as he still needs to finish of his config ? (showing him errors on the change would possiblly even worse experience ... errors flying around all the time) i like what @jimmyjones2 is suggesting ... maybe some variation of that could be nice. |
cjcenizal
force-pushed
the
improvement/visualize-floating-play-button
branch
from
a8853c2
to
94b1570
Compare
|
I made some changes so now the form controls are both close to the form and visible at all times. This should solve the "Where's my buttons?" problem.
|
|
@cjcenizal this is much more natural to me. It will also open up room for additional tabs if they are ever needed. |
| * 1. Allow user to scroll to see clipped nav items when the nav is too short. | ||
| * 2. Style the scrollbar to look good in Chrome and Safari. | ||
| */ | ||
| @mixin verticalScroll { |
| @@ -0,0 +1,7 @@ | |||
| .fullWidth { | |||
There was a problem hiding this comment.
Normally this kind of file ends up being called "utility" in frameworks. I'm guessing we'll add a lot more stuff to it over time (especially as we add more strict spacing guidelines). We might want to prefix it as such so that people understand they are their own things not tied to the classes they overwrite. .kuiUtility--thing
cjcenizal
force-pushed
the
improvement/visualize-floating-play-button
branch
from
94b1570
to
5cbde53
Compare
|
@snide I created #11360 to rename those utility classes, since it's a pretty broad change. Are you OK with moving forward with this, and making additional sidebar changes in a separate PR? If so, can you approve the PR? @thomasneirynck Would mind reviewing this in Peter's absence? |
|
@cjcenizal Yep. That's fine. I'll have a separate PR to clean up the rest. |
|
cc: @ppisljar @thomasneirynck since this is visualize, I'd be curious to hear your feedback for this implementation. |
cjcenizal
force-pushed
the
improvement/visualize-floating-play-button
branch
from
eae15d1
to
4cc3b38
Compare
|
@ppisljar Would you mind reviewing this? @snide Can you approve this PR if you're OK with the design changes? I made the Visualize sidebar background white, to clearly associate the action buttons at the bottom with the form content. In so doing, I also changed the background color of the Discover sidebar and the Management Index Patterns sidebar. I think this is an improvement:
Note that I also had to temporarily add gray lines to separate the content from the sidebar. Once this is merged, I'll move forward with fully integrating the UI Framework SideBar component with Discover and Management, so we can remove these temporary styles. |
|
actually I don't think I can add much here when it comes to the implementation ... this is now part of UI framework and when it comes to visualize all it does is include that component ... no java script at all. so if design aspects are finalized and everybody is on board with that then i think we can move forward. i am wondering if changing discovery and management fits in this PR ? |
|
@cjcenizal @snide I assume we're targeting this to 6.0 rather than 5.5? It seems like a pretty big UX change, and a major release is probably more appropriate for that. What do you think? |
|
@ppisljar @tbragin Personally, I think versions should exclusively bucket BWC breaking changes (strictly from an API point of view) and new major features. I think we should be comfortable rolling out UI/UX improvements as soon as we're confident in them, so that we're benefiting our users as soon as possible. I think you're right about the size of this UX change though. I'd like to enlist @alexfrancoeur's help in doing some user testing to increase our confidence in this change, before we merge it. |
cjcenizal
force-pushed
the
improvement/visualize-floating-play-button
branch
from
4cc3b38
to
d636a3c
Compare
|
++ on user testing @cjcenizal |
|
++ on user testing, personally i would vote for 6.0 ...
|
- Create and implement SideBar component. - Float controls at bottom of the SideBar.
…and docks the controls at the bottom of the screen.
… and content in Discover and Management Index Patterns.
cjcenizal
force-pushed
the
improvement/visualize-floating-play-button
branch
from
d636a3c
to
51b30ae
Compare
|
This is blocked on usability testing, to be conducted by @alexfrancoeur. |
|
Per request from @thomasneirynck, I'm closing this for now. We'll reopen it if we find time for it. |
Addresses #10919
During usability testing, new users often had a hard time figuring out how to "run" a visualization once they had configured it. @snide had the idea to float the buttons at the bottom of the side bar.
The responsive behavior is preserved; the visualization stacks beneath the sidebar, which grows indefinitely with its content.
CC @alexfrancoeur