-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Dashboard] Add tour to Dashboard #131960
Conversation
7662c68
to
0266868
Compare
@@ -589,6 +603,7 @@ export function DashboardTopNav({ | |||
|
|||
return ( | |||
<> | |||
{dashboardState.viewMode === ViewMode.VIEW && <DashboardViewTour />} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to put the view mode tour in dashboard_top_nav.tsx
so that I could have direct access to the onClick
action of switching to edit mode - that way, either by directly dismissing it or by switching from view mode to edit mode, the view mode tour will be dismissed permanently.
Since it would have made the code much cleaner, I originally tried to do this by injecting the view mode tour alongside the edit mode tour in the Dashboard viewport and listening for changes to the view mode to trigger the ending of the view mode tour - unfortunately this happened too late and I would get the following error:
which was caused by the EuiTourStep
being anchored to the edit button, which is dynamically hidden and replaced with the View mode
button when switching from view mode to edit mode.
Very much interested in seeing if there is a better way of handling this, since I'm not a huge fan of the view mode tour code being in dashboard_top_nav.tsx
while the edit mode tour is in dashboard_viewport.tsx
(a much more reasonable place) 👍
0266868
to
d91f060
Compare
7a28794
to
b515e41
Compare
633a74f
to
25094ba
Compare
if (appName === 'dashboard') { | ||
const disableTour = JSON.stringify({ | ||
isTourActive: false, | ||
}); | ||
await this.browser.setLocalStorageItem('dashboard.edit.tourState', disableTour); | ||
await this.browser.setLocalStorageItem('dashboard.view.tourState', disableTour); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately I don't have access to the dashboard_page
from inside common_page
, so I had to duplicate the forceSkipTour
code here... Not sure if there is a better way to do this? Because I don't feel like moving the forceSkipTour
code to common_page
is the right move either... 🤷
dd8202d
to
e2c14eb
Compare
Pinging @elastic/kibana-presentation (Team:Presentation) |
@@ -370,6 +383,7 @@ export class DashboardPageObject extends FtrService { | |||
} | |||
|
|||
public async clickCreateDashboardPrompt() { | |||
await this.forceSkipTour(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eventually, we should probably go through and clean up all the different ways the other test suites are accessing dashboard... This would really help to clean up all the places where I had to put forceSkipTour()
to get CI to pass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There has been some discussion (@timductive @kertal) around adding a uiSetting
flag that would way clean up all of these tests - basically, there would be a flag that would disable all tours/notifications/callouts from appearing for users who are already comfortable with Kibana, and we could use this in our testing by defaulting it to off
for all functional tests unless that specific feature is required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added an issue #133275
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Heenawter, @KOTungseth and I reviewed the text this morning. Here are our comments.
The Discover tour ( PR 131125) does not use the title "Discover tour". To be consistent, we should remove "Dashboard tour".
Step 1
Ready to create beautiful visualizations?
Open your dashboard in Edit mode here.
Step 2
Get creative
Create charts, maps, and other visualizations that best display your data.
Step 3
Add your style
Customize your visualization to add a personal touch.
Side note: The menu that opens from the panel menu has this item: Edit lens. It should be Edit Lens.
Step 4
Adjust the time range
View data for a particular day, the last year, or whatever time range you want.
Step 5
Refine your data
Filter for only the data you want to explore.
Step 6
Make it interactive
Add Controls, or custom filters, for a more engaging experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking pretty good I just want to go over a few scenarios and see how we can handle them better.
Scenario 1: The tour takes the user to a different screen in Kibana
This happens in Step 1 where the user is taken to Lens. If the user does go to Lens upon returning to Dashboard we should automatically show them the next step.
Scenario 2: We show them a popover inside Dashboard
This can be found, for example, in Step 3 (global time filter). Showing the content of the popover above the content of the tour doesn't look super clean. In this case, we should hide the tour step while the user interacts with the global time filter. As soon as the user is done interacting with the target UI element (global time filter) we can show them the next tour step.
Currently the tour step overlaps the Create control
flyout.
Also, nit visual design feedback. In view mode, we're showing one step which to me looks a bit too wide and with too much white space. I think we could give it a width similar to the tour step for the new data view menu (which is around 300px wide).
280d5c2
to
67f23dd
Compare
67f23dd
to
7e4d19b
Compare
8f346b8
to
434231c
Compare
In order to reliably get CI to pass, this PR is dependent on #133275 being added. Basically, because these tours are automatically triggered the first time a user opens a dashboard in view/edit mode, all functional tests that rely on Dashboard are failing. While I initially went through and force disabled the tour in various locations to get CI to pass, this is a not great solution because of all the ways different functional tests access the Dashboard app - this solution has also been the source of a lot of flakiness. A much better solution, once the above issue is closed, would be to simply disable this flag for all tests by default, and only turn it on for the dashboard tour-specific tests. In the mean time, CI will simply fail unless we decide to trigger the start of the tour via a button or some other action from the user (such as how the Discover tour is triggered). I will continue improving the behaviour of the tour based on @andreadelrio's feedback as well as my own testing - however, this cannot be merged until the above is addressed 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jughosta Thanks for pointing that out! Switched over to using React Edit: Should be fixed in c969976 |
f8ae394
to
cebb207
Compare
cebb207
to
c969976
Compare
💔 Build FailedFailed CI Steps
Test Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: cc @Heenawter |
The PR that allows the tour to be hidden through an advanced setting has officially been merged in, which means I should now be able to get CI to pass reliably - the presentation team doesn't have the resources to prioritize the tour at this point, but hopefully I'll be able to get back to this soon 👍 |
Closes #131961
Waiting on #133275
Summary
This PR as a finalization + formalization of the dashboard tour that was added as part of this Spacetime project.
View mode tour
In user testing, it was found that users often didn't know that they had to hit the
Edit
button in order to start making changes. This is what we consider to be our single-step view mode tour, and it will be started automatically when the user first opens any dashboard inView
mode:2022-05-16_ViewModeTour.mp4
Note that there are two ways that this tour can be dismissed:
Edit
mode fromView
mode - this is the scenario that is shown in the video above. Note that, if the user's first time opening a dashboard is inEdit
mode, then they switch toView
mode for the first time, they should still see the view mode tour.Edit mode tour
The second thing we wanted to do was highlight some of the most useful features in
Edit
mode - this is a multi-step tour that will start automatically when the user first opens any dashboard inEdit
mode:2022-04-29_DashboardEditTour.mp4
Flaky Test Runner
Checklist
Delete any items that are not applicable to this PR.
For maintainers