Add swipe prompt overlay to visualization area #34822
Conversation
…nts can detect if they are visible
…ible and enabled.
| !prevProps.hasBeenDismissed && | ||
| !this.hideOverlayCookieSet() | ||
| ) { | ||
| // The overlay was just dismissed. Don't show it again for a while. |
There was a problem hiding this comment.
How was this time threshold chosen?
There was a problem hiding this comment.
Some details
Our usage: There's another place we use cookies to delay re-displaying a helper prompt if a person has interacted with it. #34390 - The hide toolbar helper is re-displayed one year after it is dismissed.
Usage on mobile games (comparative study): many mobile games have a tutorial when a user first downloads the game. These walk through the interactions that are required in order to play the game. The user has to successfully complete the tutorial to continue and play the "full" version of the game. This pattern is followed in Clash of Clans, TempleRun2, and Mario Kart.
Usage on console games (comparative study) - this is mostly from personal memory: Many console games have more complicated combinations of button presses. There is a tutorial at the beginning of these games. Additionally, as opportunities to use these button presses occur, they are displayed again on the screen (sometimes every time). This is pattern is followed in many first person shooter games.
Some details about swipe and this overlay:
- Swipe is significantly easier to use than the on-screen buttons. It's a significant improvement in user experience if we can teach touch-screen users to use swipe on our labs.
- Not all labs support swipe. Users might un-learn swipe if they switch between labs that do and don't support swipe.
- We don't have a "tutorial" for our labs. Users learn to interact with the labs slowly over the whole time of a course.
- (we have been considering creating a 'mobile tutorial,` but aren't there yet)
- The overlay is very easy to dismiss. You can dismiss it by hitting an arrow key, an arrow button, or touching the screen.
My thoughts after testing these out: We don't have a metric that says 30 days is the appropriate number of days, but it's a starting point. Since it's easy to dismiss and is a significant improvement to experience, 30 days doesn't seem like too often. We also don't want it showing up all the time - it could quickly get annoying if a user knows to use swipe.
|
|
||
| if ( | ||
| this.hideOverlayCookieSet() || | ||
| hasBeenDismissed || |
There was a problem hiding this comment.
is hasBeenDismissed redundant with this.hideOverlayCookieSet()?
There was a problem hiding this comment.
Thanks for catching that! It is redundant here.
There was a problem hiding this comment.
Ok. I'm realizing why I left hasBeenDismissed here. Turns out there are two reasons:
this.hideOverlayCookieSet()is important on page load, but since it doesn't change the state/props, this component won't re-render if the the cookie changes.- We override the cookie if the user has
force_show_swipe_overlayin the browser.hasBeenDismissedallows a dev to feel like they have the same functionality as the cookie without listening for the cookie
| hasBeenDismissed || | ||
| !(this.touchSupported() || this.swipeOverlayOverrideSet()) || | ||
| !buttonsAreVisible || | ||
| buttonsAreDisabled |
There was a problem hiding this comment.
Are buttonsAreVisible and buttonsAreDisabled mutually exclusive?
There was a problem hiding this comment.
There are three states the buttons can be in
- Hidden - This is the case for labs and levels that don't use the arrow buttons
- Disabled - This is the case for labs that do use the arrow buttons, but are not in the "running" state.
- Not Disabled - This is the case for labs that use the arrow buttons and are running.
We only want to show the overlay when the buttons are enabled.
For some courses, the buttons are visible on some levels but hidden on others. On these courses, the hidden buttons still get set to disabled/not disabled when the run button is toggled.
| @@ -703,6 +709,27 @@ Craft.runButtonClick = function() { | |||
| return; | |||
| } | |||
|
|
|||
| let store = getStore(); | |||
There was a problem hiding this comment.
nit / might be more trouble than it's worth: do we have an existing place to move this code into a shared/util function so we don't have to duplicate it between the different minecraft tutorials?
| !this.hideOverlayCookieSet() | ||
| ) { | ||
| // The overlay was just dismissed. Don't show it again for a while. | ||
| cookies.set(HideSwipeOverlayCookieName, 'true', {expires: 30, path: '/'}); |
There was a problem hiding this comment.
cool! TIL how to auto-expire a cookie with js-cookie
|
Looks like something odd happened with the experiments on the drone run. Rerun is here: https://drone.cdn-code.org/code-dot-org/code-dot-org/14041 |
Currently, we support swipe actions on playlab and derivative labs (see full list below). However, users have no way of knowing that we support these actions as we never communicate it to them. This PR adds an overlay to the visualization space on the levels where swipe is supported.
The swipe overlay is displayed when all of the following criteria are met:
force_show_swipe_overlayflag in the browserThe swipe overlay will be dismissed by any of the following actions:
Overlay (4 arrows and the pointer):
Relevant Labs
Swipe supported:
Swipe not supported:
Links
Testing story
Reviewer Checklist: