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

Story education viewer messaging. #27194

Merged
merged 5 commits into from Mar 17, 2020

Conversation

gmajoulet
Copy link
Contributor

Story education viewer messaging:

  • Sends a message on build to display the tap + swipe navigation screen
  • Only sends messages when the doc gets visible, to avoid receiving messages from multiple prerendered docs
  • Stops propagation on touch events so they're not forwarded to the viewer, disabling the "swipe to next" feature (and the navigation hint overlay)
  • Adds an EDUCATION_STATE in the store service and expose it to viewers, so they can block swiping interactions while it's on if they're using native gestures

#27097

Copy link
Member

@danielrozenberg danielrozenberg left a comment

Choose a reason for hiding this comment

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

Approval for build-system/tasks/presubmit-checks.js

.resolves();

storyEducation.buildCallback();
await Promise.resolve(); // whenFirstVisible icrotask tick.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: s/icrotask/microtask

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Trying to fix this with the "suggestion" feature 👀

@@ -104,6 +118,23 @@ export class AmpStoryEducation extends AMP.BaseElement {
true /** useCapture */
);

// Prevent touchevents from being forwarded through viewer messaging.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we remove these at some point?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's actually what has been discussed, the issue being that the second screen says "swipe" but if we don't prevent the touchevents from being forwarded, users would be sent to the next story. :(

Copy link
Contributor Author

@gmajoulet gmajoulet left a comment

Choose a reason for hiding this comment

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

PTAL

@@ -104,6 +118,23 @@ export class AmpStoryEducation extends AMP.BaseElement {
true /** useCapture */
);

// Prevent touchevents from being forwarded through viewer messaging.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's actually what has been discussed, the issue being that the second screen says "swipe" but if we don't prevent the touchevents from being forwarded, users would be sent to the next story. :(

.resolves();

storyEducation.buildCallback();
await Promise.resolve(); // whenFirstVisible icrotask tick.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Trying to fix this with the "suggestion" feature 👀

@@ -51,6 +52,11 @@ const buildNavigationEl = element => {
`;
};

/** @enum {string} */
const Screen = {
ONBOARDING_NAVIGATION: 'on',
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe be more descriptive about what this screen is? These names (the minified on version) are permanent since they'll be embedded in other viewers that we can't change, but I wonder if e.g. we experimented with multiple versions of onboarding, how we would tell them apart

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean descriptive as in adding a comment in our codebase, or changing the on word to something more verbose?

If the latter, wdyt of something like: ONBOARDING_NAVIGATION_TAP_AND_SWIPE: 'ontas?

Copy link
Contributor

Choose a reason for hiding this comment

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

I meant the latter, and yep, your suggestion LGTM!

)
.then(response => {
const shouldShow = !!(
response &&
Copy link
Contributor

Choose a reason for hiding this comment

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

Man, optional chaining would be great.....

// screens, if/when needed.
this.viewer_
.sendMessageAwaitResponse(
'canShowScreens',
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I'm not entirely sure about making this plural; this seems like it could lead us to want to request multiple and cache the result, whereas I think the idea is to lookup can show at the instant the screen is to be displayed, in case things have changed

The inner object notation LGTM, but we should document

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The motivation behind making it plural is that we want to know how many total screens we are going to display at a given time to:

  1. Have accurate "Tip 1/n" labels
  2. Not animate out / animate in again between different screens

Copy link
Contributor

Choose a reason for hiding this comment

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

But, this is one "screen" right? So (1) can't the tip labels be hardcoded? (2) would it do that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe I'm over engineering this: if tomorrow we add more screens, say audio controls, we might ask players if they want to show the navigation screens, and the audio controls screen on load.
If we don't ask that in the same message, there might be a delay in between both screens causing (2), and inaccurate "Tip 1/n" hardcoded labels

Copy link
Contributor

@newmuis newmuis Mar 13, 2020

Choose a reason for hiding this comment

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

👍

I guess I'm also fine with an array and a comment on the format side that says we shouldn't cache these values

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good.
The format side should always display all the screens right away (one by one), but not store the response to be used later.

@gmajoulet gmajoulet force-pushed the education_navigation_messaging branch from 4b7bed4 to 43da571 Compare March 13, 2020 21:18
@gmajoulet gmajoulet force-pushed the education_navigation_messaging branch from d8a206b to db760c4 Compare March 16, 2020 19:07
@gmajoulet
Copy link
Contributor Author

I'll merge this before the canary cut today cc @newmuis

@gmajoulet gmajoulet merged commit 2ff07eb into ampproject:master Mar 17, 2020
twintwox pushed a commit to twintwox/amphtml that referenced this pull request Mar 24, 2020
* Story education viewer messaging.

* s/icrotask/microtask

* s/on/ontas

* Add comment to not cache viewer responses.

* Update tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants