AMP Plugin Team — Weekly Sync - 9th June 2021

[maitreyie-chavan]

Attendees

@amedina, @westonruter, @schlessera, @rahul286, @pradeep910, @jwold, @maitreyie-chavan, @kenrodriguesdesign, @adamsilverstein

Meeting Notes

• @westonruter gave an overview of the work areas for AMPˣ plugin that he had been working on -
• This was to put together thinking of high level areas that could work in parallel and order of things that need to be done
• Contribution towards Bento components can happen in an isolated manner with the focus on Newspack based stats
• We will then have integration of those into the AMP plugin, unlocking more modes to explore
• Currently, we have a strict AMP and non-AMP world along with 3 templates modes trying to fit into that binary world
• With the addition of Bento, we will be able to have sandbox levels where we use Standard mode but then we convert things to Bento where possible and leave the things that we can’t e.g custom scripts and it unblocks the owners who are using unsupported AMP providers/analytics/widgets/social engagement tools etc that have wanted to use on AMP pages but haven’t been able to
• Level 1 sandbox mode - it would be for the basic use case, where we convert to Bento when possible but don’t strip anything out and just know there’s sanitising happening.
• Level 2 sandbox mode - would be where we convert to Bento components when possible but remove things that are not Bento components/Web components. This would be ideal in a world where we have more Bento components than AMP components (which isn’t there yet but could happen), then maybe Jetpack could ship a wp-com like Bento component and code be on a page where it does not get stripped away as it is a Bento component, it would more performant than done with custom JS
• Level 3 sandbox mode - is what the plugin does currently with AMP validator, anything that is not there in AMP validator spec it gets stripped off.
• In some way L1 and L2 is possible today too, we have to manually mark ‘Keep’ the invalid script and the process of doing that is not user friendly and requires technical know-how.
• In some cases for the Bento version of the AMP component the API has changed a bit, every attribute has changed name or in the case of amp-carousel there's an amp-base-carousel Bento component but not an amp-carousel. To facilitate existing code that must be generating old classic AMP component markup we need to have a transformer/optimiser/ tool that automatically updates classic AMP components to Bento components and there’s no work that needs to be done by users or ecosystem - that will be a great aspect to have these kinds of transformation is place
• Moving to AMP Compiler - it’s still TBD but the known update was that there will be a way to create a PHP based implementation so that we don’t have to integrate with SaaS to obtain the optimised Bento version
• Once we have the sandbox levels flushed and working, we would want to discourage the use of transitional mode as it won’t be helpful to have two different versions with the same templates where some functions work in one version but don't in other
• @adamsilverstein and @schlessera - How will it be determined about what is considered as valid and invalid Bento for L2?
• Valid would be a Web component. We will need to have a way of indicating what scripts are loading Bento components on the page whereas for AMP components now it is coming from AMP CDN. The certification of a component is powered by the AMP Validator spec, we need to have a way to identify what is not in the spec. A naive approach would be to say if it’s a web component, allow it and the scripts would need to have an attribute to help map it with the Bento component
• @amedina mentioned the wish to be able to convey to a user how close they are to achieving good PX
• With regards to the design evolution for the onboarding wizard and settings page, behind the screen it should be able to detect the recommended template mode and sandbox level that works best for a site. For most sites it may recommend Standard mode with L1 or just Reader mode. And the plugin could suggest that if you use any of the compatible extensions that we have vetted then you could go to a L2 or L3. This will help with the ecosystem activation related activities and gather enough insights to provide users with valuable suggestions
• Another area would be Support, it would include incorporating workflows for data to be a part of the compatibility DB, identifying pain points, ecosystem outreach, etc
• Next week’s meeting would be building over what was discussed during this meeting and focus on chalking out the release plan against a targeted feature list