Editor’s note: the following was originally posted on AddThis’ blog by Chad Edmonds, Sr. Marketing Manager, AddThis

Just because AddThis is now free, doesn’t mean we’re slowing down on pushing out more great features and functionalities! We recently rolled out AddThis Inline Share Buttons for AMP and it is ready for you to integrate into your AMP compatible site.

A bit of background: AMP project (spearheaded by Google and others) is a new open source initiative that stands for Accelerated Mobile Pages and is meant to improve the mobile web browsing experience by speeding up ensuring web pages are fast and smooth loading. There are also a few other advantages to setting your website pages up for AMP, like additional traffic from platforms that link out to AMP websites like Google and Twitter. Learn more about creating your AMP page here.

We’re excited to be joining the initiative to improve the content ecosystem and we believe users should still have the same functionality on AMP that they have on other platforms. That is why we’re one of the first third-party plugins to be available as an AMP component.

Ready to get started? Visit our Academy article or YouTube video to learn how to install AddThis Inline Share Buttons on your AMP site!

In the coming months, we will be rolling out more AMP capabilities as well as more robust support documentation. In the meantime, if you have any questions or feedback about the plugin, please do not hesitate to reach out to our support team.

Posted by Chad Edmonds, Sr. Marketing Manager, AddThis

Early choices in designing the AMP HTML JavaScript library have made it uniquely suited for publishers to implement effective privacy controls for users. In web pages, resource requests and browser storage access that may have privacy impact can be initiated through a multitude of mechanisms, many of which are often controlled by third parties. This may make it hard for a publisher to ensure that no unintended actions are performed before, for example, appropriate user consent is obtained. This post is looking at a software architecture within AMP that may aid publishers to effectively implement such user choice options. For concrete steps to implement user choice flows in AMP documents, please check out this blog post.

Privacy-preserving prerendering

One of the key ways how AMP differentiates itself from general HTML documents is that it has the capability of privacy-preserving prerendering built-in. This is a user privacy requirement to implement instant loading of documents.

Instant loading naturally requires loading a document that a user might see before the user has navigated to it. By loading it before the user expressed intent, network operations can be executed by the time user finally does express intent (e.g. by clicking a link), making the load time much faster.

Instant loading is clearly a great user experience, but it does come with a privacy challenge. If a user never ends up looking at a document that was prerendered, then the publisher might still receive signals and information about the user through the pre-rendering of the document. This is a change from how the web usually works, and may not be what users expect. For this reason, we designed AMP such that it would not allow a publisher of a document to know that pre-rendering of a web page is happening until the user expresses intent to actually go to the web page. This is what we call privacy-preserving prerendering.

Privacy-preserving prerendering is implemented in AMP via 2 primary mechanisms that work together:

1. A platform-controlled AMP Cache that does not expose user request data to a publisher of content.
2. A centralized request manager that controls the timing and availability of resource requests from web components on AMP pages.

Let’s look a bit closer at the second mechanism: Whenever an AMP page loads any resource, such as images, videos, ads, analytics requests, tweets, or any of dozens of other types of resources, the associated network requests are controlled by a central resource management mechanism. This resource manager, in addition to performing many other functions, also ensures that requests that are not allowed during the prerendering phase of a document lifecycle are held back until the document learns that the user expressed intent to see the page.

Diagram of the process to load a resource in the AMP JS library.

This is the key architectural feature of AMP that makes it uniquely suited to implement more sophisticated privacy controls on top of this baseline mechanism.

An architecture for supporting user choice

The previous paragraph talks about how AMP controls resource request timing to ensure that certain requests made during the prerendering phase are only actually made after a user has expressed intent to visit a page. From a software architecture point of view, this introduces a central mechanism to control request timing, making it relatively easy to then introduce additional rules, including rules specified by the publisher of the page, for delaying requests on top of the pre-rendering specific rules.

For example, one such publisher-specified rule could be to delay any ad requests on an AMP page until the publisher has obtained sufficient user consent to make such ad requests or share ads-related data with an ad vendor.

For each AMP web component (such as the amp-ad and the amp-img elements), a publisher can specify that the associated resources should only be loaded if the user has provided consent that the publisher has determined is needed to load and display the respective resource.

Diagram of the process that determines the flow to requesting a resource in the AMP JS library.

While a publisher may still need to perform an audit of the types of AMP web components they load on their page and determine whether any form of user consent may be needed to display them, having a unified mechanism to control the behavior of all resource types that may be included in a page–from images, over ads, to analytics–should make it easier for a publisher to gain confidence that they applied the consent treatment to the full spectrum of resources and behaviors where it is needed.

This post looked at privacy-enhancing functionality from a software architecture point of view. For concrete steps to implement user choice flows in AMP documents, please check out this blog post.

Posted by Malte Ubl, Tech Lead of the AMP Project.

As the AMP project grows, we want to ensure that the community has a clear understanding of the features the team is working on and the status of each. Starting today, you can head over to the AMP roadmap and see an updated view of feature development across the project. We hope this is easy to understand and offers better insight about what each feature means. As a developer, you can also continue to look at the release logs on a per release basis.

Each feature can be in the “Next Up”, “In Development” or “Shipped” categories.

If you are interested in more detail, you can click on the heading of the issue and navigate directly to the GitHub issue to learn about associated issues or pull requests.

Here are some features we specifically wanted to call your attention to:

AMP stories

• Monetization Support — Publishers can now use DoubleClick for publishers to serve direct-sold, premium advertising to AMP stories. Next up, we are looking at supporting HTML5 story ads over this quarter.
• Learn about other stories related features in the blog post here.

New UI features

• amp-date-picker — this is a full-featured date-picker for e-commerce use cases
• amp-next-page — this feature, which supports the “infinite scroll” of page-level content like new articles or blog posts, is now available as an experiment on particular documents.
• amp-date-countdown — this component, generously contributed by community members, supports a dynamic countdown to a specified date & time, primarily for e-commerce use cases like limited-time sales.

Upcoming Features

• 1-line PWA — A large area of effort for the team is to figure out how to make it trivially easy for developers to create a PWA, given an AMP document. This includes smart caching and prefetching, as well as a way to ensure seamless page transitions associated with single-page apps directly in AMP.
• amp-consent — We are continuing to enhance amp-consent functionality by providing publishers with the ability to fold their existing consent flows into AMP pages and manage consent status across AMP and non-AMP pages. We are also looking at supporting the IAB framework for user consent management.
• AMPHTML ads — Over the next quarter, we will continue to work at improving the performance of AMPHTML ads, especially when served to non-AMP pages. In addition, we will also work on supporting AMPHTML ads in mobile app environments.
• ID Link Decoration — We’re making page measurements easier by introducing ID Forwarding on AMP pages. The updates will help you see accurate metrics of your users and their journeys on your properties.

As always, if you have questions or suggestions, please share your feedback.

Posted by Vamsee Jasti, Product Manager, AMP Project

We announced the developer preview of AMP stories in February at AMP Conf. Since then, publishers have authored thousands of stories, experimenting with the format and providing valuable feedback to the AMP team. Based on this input, we recently released new capabilities in AMP stories v1.0, open to all developers without origin trials or a whitelist. New features include:

• New monetization capabilities, including ads served from DFP as shown below. (Note: DFP support is in BETA, please reach out to us if you are interested in testing).

• New metadata attributes for surfacing stories in platforms and displaying a preview of the story across the AMP stories ecosystem.
• Revamped bookend capabilities with richer options including call to action links, text boxes, and portrait and landscape cards

Version 1.0 of AMP stories includes these updates and is available today. Upgrade your existing stories to v1.0 using our migration guide to take advantage of the new features.

Stay tuned for more developments in the coming months; you can see the full roadmap here. The team is actively working on additional features including:

• Paywalls
• Responsive scaling
• Additional clickable elements

As always, if you have feedback, please let us know on Github. We look forward to seeing more publishers try AMP stories!

Posted by Jon Newmuis, AMP Stories Lead Engineer, Google

 

Earlier this month we announced a limited release of amp-date-picker, a calendar-style interactive date picker for form input. With this component users can specify single dates or date ranges with a calendar interface that makes the process faster and less error prone. After a great round of feedback from developers trying it out on their pages, we’ve fixed a number of bugs and added some feature requests, like the ability to quickly toggle the current date. With these updates, the date picker is now fully launched to production.

 

 

Check out the sample on AMP by Example to see how to use it and what it can do. As always, let us know if you have any feedback for amp-date-picker, or for any other feature gaps in AMP. We look forward to hearing from you!

Posted by Eric Lindley, AMP Product Manager

We are happy to share that the first AMP Contributor Summit for developers in AMP’s open source community will be held in San Francisco, California this September!

The summit will take place from September 25-26, with an optional New Contributor Day on September 24th that’s especially for people new to contributing to AMP.  If you are a developer who contributes to AMP–or a developer who wants to start contributing–please apply to attend!

The AMP Contributor Summit will bring the AMP open source community together in one place for the first time.  The summit will provide an opportunity for the community to:

• Meet each other in person.
• Share the latest knowledge about developing in AMP–from relevant web technologies that are important for AMP contributors to know to how-tos on AMP architecture.
• Enjoy deeply technical talks about the internals of AMP and how they could change in the future.
• Review what we’ve accomplished in AMP so far and discuss what AMP’s priorities should be going into the future.

The main summit takes place on September 25th & 26th.  These days will feature talks, breakout sessions, hacking–and plenty of breaks and opportunities to meet other developers in the community.

On September 24 we’ll have an optional New Contributor Day to get new contributors up to speed on contributing to AMP before the main summit starts.  This day of talks and codelabs is meant for people who want to contribute to AMP but who haven’t yet started.

The talks at the summit will be given by people in the community.  If you have an idea for a talk you would like to give at the summit please submit a proposal for a talk by July 31, 2018.  Please note, that this is a technical summit and don’t worry that your talk might not be polished enough. We’re excited to hear from everyone!

See the AMP Contributor event page for more information and to apply to attend.  We hope to see you in September!

Posted by Joey Rozier, AMP Engineering Manager at Google

Editor’s note: The following was originally posted by Adam Silverstein, Lead Web Engineer at 10up on the Google Open Source Blog.

I started my web career building websites for small businesses on WordPress, so when I decided to begin contributing to open source, WordPress was a natural place to start.

Now I work at the digital agency 10up, where I am a part of our open source team. We build popular sites like FiveThirtyEight where having the best possible AMP experience is critical. However, bringing FiveThirtyEight’s AMP version up to parity with the site’s responsive mobile experience was challenging, in part because of advanced features that aren’t directly supported in AMP.

One of those unsupported features was MathML, a standard for displaying mathematical formulas on the web. To avoid a clumsy work around (amp-iframe) and improve our presentation of formulas, I proposed a native `amp-mathml` component which could display formulas inline. Contributing improvements “upstream” to open source projects – especially as we encounter friction in real-world projects – is a core value at 10up and important to the health of the web. I expected that I could leverage the same open source MathJax library we used on the responsive website for an AMP implementation. Contributing this component would strengthen my understanding of AMP’s internals while simultaneously improving a client site and enabling the open MathML standard on any AMP page. Win, win, win!

I started by opening an issue on the amphtml repository, describing MathML and proposing a native `amp-mathml` component. Justin Ridgewell from the AMP team immediately responded to the issue and asked Ali Ghassemi to track it. I offered to help write the code and received an enthusiastic response, encouraging me and assuring me that the team would be available on GitHub and in Slack to answer any questions.

This warm welcome gave me the confidence to dive in, but ramp up was daunting. The build tools and coding standards were quite different from other projects I work on and setup required some editor reconfiguring and reflex retraining. Getting the unit test to run on my system required tracking down and installing some missing dependencies.

Fortunately, AMP’s project documentation is thorough, and Ali guided me through the implementation, pointing me to existing, similar samples in the project. I already knew how to use JavaScript to render formulas with MathJax – my challenge was building an AMP component that ran this code and displayed it inline.

After a few days of concerted effort, I built a proof of concept and opened a pull request. The real fun began as I refined the approach and wrote documentation with help from the team. The team’s active engagement helped the process move along rapidly. Amazingly, the pull request was merged one week later, and today amp-mathml is live in the wild. FiveThirtyEight is already using the new, native implementation.

From opening the issue all the way to the merge of my pull request, I was impressed by the support and encouragement I received. Ali and honeybadgerdontcare provided regular reviews and thorough suggestions on the pull request when I pushed iterations. Their engagement throughout the process made me and my work feel valued, and helped me stay motivated to continue working on the feature.

Adding MathML to AMP reminded me why I find so much joy and professional growth in contributing to open source projects. I have a better understanding of AMP from the inside out, and I was welcomed into the project’s community with wide open arms. I’m proud of my contribution, and ready to tackle new challenges after seeing its success!

Posted By Adam Silverstein, Lead Web Engineer at 10up, and AMP Project contributor

We made the Shadow Reader even faster – and friendlier to search engines!

We created the Shadow Reader to demonstrate how AMP pages can be used within a Progressive Web App (PWA) (read our announcement post for more context). The site repurposes existing articles from The Guardian into an immersive news reader experience. More than just a demo, it’s intended to be a fully functional site. It contains the end-to-end code needed to effectively combine AMP and PWA… it’s ready for production!

 

SEO for JS-generated content

As in any self-respecting single page application, the Shadow Reader’s initial HTML payload is small. It’s a thin app shell that loads quickly, giving the user something to look at while JavaScript loads the main content. This approach makes for a fine user experience!

Unfortunately, it can also present a challenge to search engines. Google will try to execute JavaScript in order to index what ultimately appears to the user, not just the initial HTML. But many search engines don’t or do so unreliably. In other words, it’s not safe to depend on a search engine to successfully execute your JavaScript. And if a search engine sees only the app shell, minus most or all of the content, it won’t be able to properly index the page.

Wouldn’t it be nice if the Shadow Reader’s article pages were served to search engines with text included right in the HTML?  And wouldn’t it be amazing if that process didn’t slow down rendering, but instead gave us a way to serve those pages to new users in less than a second?

Turns out we can do both of those by serving the AMP version of articles to new users!  After all, a web crawler appears to a server as a new user, too. So… how did we do it?

 

AMP⇒PWA

We did this by implementing an AMP⇒PWA pattern. Here’s how it works!

For a new user:

• When a new user visits an article page, we serve the AMP version of the article.
• The AMP uses <amp-install-serviceworker> to load and install the service worker.
• The service worker loads and caches the app shell.
• On the next page navigation, the service worker is in control – and so it gently brings the user into the PWA on that next page.

For an existing user, we simply serve the PWA.

That’s how our site can treat new users and existing users differently at the same URL. For existing users, the service worker is installed. And, when the service worker sees an article URL, it serves its cached version of the PWA.

How does this play out in the Shadow Reader?  Let’s say a user first visits this article page:

https://amp.cards/theguardian/us/amazing_article

Seeing an article URL, the server returns the AMP version of the article, but one that installs a service worker when the article is loaded. The service worker, using the Workbox library, contains this line:

workboxSW.router.registerNavigationRoute('index.html')

This means, whenever the user navigates to a new URL on this domain, the service worker sees that request, and instead of passing it along to the server, it simply serves its cached version of index.html. That’s our PWA.

So if the user next clicks on a link to

https://amp.cards/theguardian/us/another_article

the service worker serves the cached PWA HTML. But the URL is unchanged!  So when the PWA looks at the URL to parse out what article is being requested, it sees the link the user requested, and it can load the proper article into the PWA.

Thereafter, any time the user requests a Shadow Reader link, the service worker is already installed, and it serves the cached PWA.

Since a web crawler won’t allow us to install a service worker, a web crawler always gets served the AMP article.

 

Here’s that flow in a lovely diagram:

For a new user:

1. The browser requests an article URL from the server. The server returns an AMP version of the article that includes <amp-install-serviceworker>.
2. AMP’s serviceworker JS causes the browser to request the service worker. The server sends the service worker JS to the browser. The browser installs the service worker and starts it up.
3. The service worker sends the server a request for the PWA app shell. The server sends those resources to the service worker, which caches them.

For an existing user:

1. The browser sends a request for an article URL. This request is intercepted by the service worker. The service worker returns the cached PWA to the browser.
2. The PWA requests the AMP article. This requests reaches the server, which returns the AMP article to the PWA. The PWA processes and displays that article.

Remember, a web crawler is always a new user!

 

What’s next?

Now that the Shadow Reader’s got its own server, we’ve got some new TODOs:

• In the future, we could forgo YQL altogether, simply using the Guardian’s RSS feed directly.
• We also should replace the Guardian’s top nav links with Shadow Reader links.
• We ask the AMP Cache to download and run the entire Shadow Reader in an iframe: <amp-install-serviceworker data-iframe-src=”https://amp.cards/index.html“>. It might be kinder to the casual user to specify a smaller page instead.
• Backend.js now gets used in the server as well as the front end, and the way we do that is a bit hacky. Perhaps we should refactor our code to use ECMAScript modules?

Please try this out, check out the code on github, and let us know what you think!  We’re curious about how you’re trying out AMP/PWA patterns on your own site, and we’d love to get your ideas for Shadow Reader improvements.

 

Posted by Ben Morss, Developer Advocate, Google

Monetization support for AMP stories

AMP stories now supports ‘Publisher placed ads’, the ability for a publisher to serve ads for which they can control delivery sales and delivery. Ad Server support in DoubleClick for Publishers (DFP) is planned for the end of June. We urge other ad networks that are interested in adding monetization support to AMP stories to reach out to us.

See the details related to monetization related to AMP stories here or play with an example on AMPbyExample.com.

New user control tools in AMP

We have launched the new <amp-consent> component to help publishers implement user controls for customizable notice, choice, and consent flows. You can find all the usage and integration details related to the launch in this blog post.

Relatedly, a new component, <amp-geo>, makes it easy to vary small sections of web content for users based on an approximation of the users’ country-level location, similar to the level of an ISO Country Code. This can be used with <amp-consent> to change the behavior of <amp-consent> based on users’ approximate location. Check out an example to see how the two components integrate.

AMP Date Picker (Experimental)

The <amp-date-picker> component is a calendar-style interactive date picker for form input, and it’s officially available to use on sites as a document-level experiment. This means that developers can use the component as long as they also include this temporary tag: <meta name=”amp-experiments-opt-in” content=”amp-date-picker”>. Check out the sample on  AMP by Example to see what it can do, and determine if it’s right for your site.

Note: The reason for this intermediate stage of release (a document-level opt-in) is to collect feedback from developers and users and to identify any issues before we consider the component stable enough for a full production release. So expect some rough edges for now, let us know if you have any feedback, and stay tuned for the full release later this quarter.

Introducing the image lightbox gallery

Since AMP launched, developers have been asking for an easy way to link <amp-carousel> with <amp-image-lightbox> so users could experience an immersive view of content in carousels. While it’s been possible to combine numerous components (like <amp-bind>) to make something like this work, it hasn’t been easy.

The <amp-lightbox-gallery> component provides an immersive media experience that can stand on its own or can be integrated with the amp-carousel. The component can be applied to a standalone image or to a group of images so that when a user taps on these images, they enter an immersive view where they can seamlessly swipe from image to image. When <amp-lightbox-gallery> is applied to an <amp-carousel>, all images in the carousel inherit the lightbox gallery behavior so that swipes between items in the immersive view are synced with those in the lightbox, to create a smooth, intuitive gallery experience.

New effects for amp-fx-collection

We’re just starting to build out <amp-fx-collection>, a suite of easy-to-use visual effects that developers can use to make their sites more engaging. So far, we’ve released two effects: parallax, which lets you easily configure page elements to move at different speeds relative to the scrolling speed of the document; and fade-in, which applies a simple and configurable fade-in effect when the user scrolls content into view. Over the next few weeks, we’re planning to launch fly-in as well, which is currently available as an experiment. Check out the new features on AMP by Example and let us know what you think.

Ability to upload files

File upload is an important capability for many sites.  For instance, some e-commerce sites incorporate custom design uploads into their purchase flows. To support this functionality we enabled file upload support in forms through <input type=”file”>(essentially the same way developers would do this in a non-AMP page, with the additional requirement that the form uses a secure XHR submit). And now that AMP offers this basic support, we’re working on a more advanced API that will allow developers to better communicate to users the status of file uploads (bytes uploaded, % progress bars, etc).

The best of the rest

• Read more about the progress on web packaging to help get rid of google.com/amp URLs when AMP documents are loaded from the Google AMP cache.
• A number of talks and features were delivered at Google I/O 2018. You can read the summary of the AMP team’s presence at I/O here.

Upcoming features worth a shout

• A number of potential features related to amp-consent are being discussed at the moment
• Full launch of the date picker mentioned above
• Video features, including minimizing video to the corner of the viewport and fullscreen-on-rotate
• Two types of “infinite scroll” experiences: one for full documents, and one for page elements in a list

* * *

Thanks to the AMP development community for your work and feedback. As always, please let us know if you have any issues or feature requests.

Posted by Vamsee Jasti, Product Manager, AMP Project