Amphtml: Intent-to-Deprecate: amp-sidebar in amp-story

[newmuis]

Summary and Motivation

The <amp-sidebar> feature in stories has not achieved scale, but is creating an inconsistent user experience. It has also been brought up that the feature is an anomaly, as it's not one that's generally supported in story platforms. This has been demonstrated by the low adoption since launch, as compared to other features.

Alternative implementation suggestions for publishers

Rather than using links within a sidebar, publishers can look to these following suggestions:

1. Publishers can use <a> tags directly within their <amp-story-grid-layer> or <amp-story-cta-layer> tags
2. Publishers may load additional context in <amp-story-page-attachment>
3. Publishers can use <amp-story-player> to embed their story in another page, containing custom UI to present this data

Additional Context

We would like to start triggering warnings to inform publishers of the deprecation on a wider scale. After the warning period, we will deprecate the feature by removing its documentation and making its markup a no-op (to prevent invalidating documents).

In the future, we can file a separate I2R to invalidate the <amp-sidebar> markup within <amp-story> at a time where its impact is minimal. Before doing so, it may be a good idea to update the deprecation notice with a concrete removal date.

[newmuis]

/cc @ampproject/wg-approvers

[Gregable]

Do you have data you can share on the low adoption rate?

[newmuis]

• 99% of stories using <amp-sidebar> are published by only 15 publishers
• Stories using <amp-sidebar> amount to at most 0.2% of all stories.

[cathyxz]

That means https://github.com/ampproject/amphtml/issues/24827 will no longer be relevant, and this can unblock moving amp-sidebar's mask from body to inside the component. /cc @ampproject/wg-ui-and-a11y

[Beethoven]

I think it should be optional.
Sidebar is essential to navigate on a Story using branching and to put Social links, terms etc.
Amp Story is a web page in essencial and needs a MENU.

Example:
https://stapp.app/ferrari

[newmuis]

AMP stories are webpages, but they're also stories, and the question becomes: which one takes precedence?

To build out the feature set that users expect when they engage with story content, generally the story definition takes precedence.

I think it should be optional.

This is the core of the problem. Optional from whose perspective?

• If we want to make this optional for publishers (i.e. a publisher can choose to include or not include a sidebar), this is the current state of affairs. It creates the problems described above.
• If we want to make this optional for consumption platforms (i.e. a platform can choose whether or not it wishes to display a story's sidebar), then this creates inconsistent expectations. Publishers might publish their stories to their own sites and be completely unaware that other sites are effectively changing the contents of their stories. If the angle here is to make this more like traditional web content, that's not how websites are generally treated, either.

Deprecation leads to consistent expectations for all parties, across all surfaces. The workarounds presented above also allow publishers to achieve linking behavior in their stories without a sidebar, or allow them to create a sidebar in conjunction with <amp-story-player>.

[Kevin-Ellen]

My 2 pence for what it is worth.

In my opinion a 'menu' is slightly redundant in this context, as it is hard to directly link to a specific page from outside sources (you are forcing users to navigate through the story) and the URLs do not change; given that a Story is not a website, but a single page application.

A Story is a single page, which feels like a website; and only till we start supporting individual URLs per page, would it make sense.

As for social media links and engagement, we should use attachment in my opinion.

What about being allowed to use page attachment from different positions? So not just bottom of the screen, but also either top, right or left?

---

EDIT (as I was wrong):

..., as it is hard to directly link to a specific page from outside sources...

It is easy to link to a specific page from outside sources; just add the ID in a hash to the URL and the browser will find it.
<amp-story-page id="test-page">
A link to #test-page will automatically jump to that page; so that is how linking to a page (and from amp-sidebar) can be easily done.

[Beethoven]

Page attachment is a per page component and cant't serve as MENU.
Page attachment is a "SWIPE UP TO SEE MORE" component not a MENU.
Amp Story is a website that uses a stories UX.
We need to think in users as the creators of the amp stories sites, not only as the consumers who see.
We need to ask the consumer if they want a menu on his stories site or not.
For me Publisher can be anyone.
We have more than 4m stories sites with sidebar and we can help with statistics.

[Kevin-Ellen]

Page attachment is a per page component and cant't serve as MENU.

Fair enough, and affectively it should not be used as a menu indeed. I was more hinting at having worthwhile sharing opportunities and credits in attachments.

Page attachment is a "SWIPE UP TO SEE MORE" component not a MENU.

Correct.

Amp Story is a website that uses a stories UX.

I continue to disagree on this point.

We need to ask the consumer if they want a menu on his stories site or not.

Big fan of this, as we should give people options to use them or not. Especially given that amp-sidebar is already a worthwhile component.

We have more than 4m stories sites with sidebar and we can help with statistics.

I am sure @newmuis would be interested, given he posted some numbers earlier and the more data the team has, the better decision they can make. This kind of data can help the group to make a better decision.

@newmuis - while amp-sidebar is not fully taken on by many people when it comes to AMP Stories, what are the benefits of removing the support for it? The component will remain in AMP; so what is the point?

[Beethoven]

My point:
Amp Story is a website that uses a stories UX.

Think as Sales department with focus on client:
Everyone needs a website on top of Serps.
Amp Stories is a website that engages and in our analytics almost zero bounce (3% bounce).

The user doesn't need another platform to share stories.
They need a site on top of serps that convert. And a site needs a menu.
Our customer can't understand what AMP Stories is and why to build it.
But a Site on top of SERPs all of them want.

[newmuis]

Amp Story is a website that uses a stories UX.

I also disagree on this point.

AMP stories are stories that live on the open web. They're not intended to be a replacement for a website or any specific piece of website functionality. The intent is to make stories a first class citizen of the web. Put another way: we're bringing stories to the web, not bringing the web to stories.

They need a site on top of serps that convert. And a site needs a menu.
Our customer can't understand what AMP Stories is and why to build it.
But a Site on top of SERPs all of them want.

Stories are a medium, not a ranking factor. We wouldn't add a sidebar menu to video formats to help users convert, because videos are an understood medium that have an expected set of functionalities (play/pause, seek, mute/unmute, etc... but not sidebar).

My vote here is actually to handle this the same way as video: if you would like to have a video with a sidebar menu, you create a new page that contains both the video player and the sidebar menu. This is analogous to my third "alternative implementation" above: create a new page that contains both the story player and the sidebar menu.

@newmuis - while amp-sidebar is not fully taken on by many people when it comes to AMP Stories, what are the benefits of removing the support for it? The component will remain in AMP; so what is the point?

It will remain in AMP, but not valid for stories. I don't think of it as a "removal"; it's still possible to have a sidebar, it would just need to exist at the platform layer. One concrete advantage is a benefit to the user experience when embedded in consumption platforms (i.e. avoiding having the platform's menu and also the story's menu).

[Beethoven]

We want to make amp stories universally accessible to empower voices - and having a sidebar to navigate helps in its accessibility because It can be a substitution of a site.
Amp Stories is a perfect UX for a site or landpage. Like a "don't make me think site".

Since AMP Stories is html, css, js are just web pages.
Like Flavio Palandri Antonelli write on his post:
"Importantly, AMP Stories are just web pages. They have a URL on your web server, they are linkable, and they can link out to other web pages."
From amp.dev Blog

We need to ask the users if they want a sidebar to navigate on his stories or not.
For example Sidebar is perfect for a Summary.

I know amp stories are not a ranking factor. But engagement, time on site and in terms bounce is. And we are seeing Amp Stories with all of that.

When saying "when embedded in consumption platforms" is that Google can show a sequence of Amp stories of various publishers, like we saw in Visual Stories results?

[newmuis]

having a sidebar to navigate helps in its accessibility because It can be a substitution of a site.
Amp Stories is a perfect UX for a site or landpage.

This is not the intended use case of the format. I think it's okay for people to try to be creative and push the boundaries, but we should avoid making format-level decisions with ecosystem-wide implications for something that is not the primary use case of the format.

When saying "when embedded in consumption platforms" is that Google can show a sequence of Amp stories of various publishers, like we saw in Visual Stories results?

That is one experience, but you can imagine such an experience on any consumption platform. For example, imagine that a consumption platform like Twitter, Instagram, Google, etc wished to show AMP stories in their app, alongside their existing content. Wouldn't it be weird to allow sidebars in that context? The UX would conflict with platform-level controls (e.g. the platform might have a sidebar of their own that would conflict with the publisher's). As such, it would be a blocker for adoption from such platforms.

Hence the recommendation: let publishers have full control to create sidebars on their own platforms, that makes sense. Publishers of course can still include links as part of the story content itself, but sidebars, as a platform-level feature, should live with the platform.

[Beethoven]

I understand now. And now I can vote to deprecate it too.
We will love to see amp stories on platforms, and the efforts to make it accessible.
We just need an example to use sidebar with amp-story-player accessing pages. It is possible?
And tks for the replies.

[newmuis]

Agreed, it would be great to have an example of this; I can own writing this up.

[Beethoven]

We can help with examples too. (if we know how to do it)

[AutadeJS]

Agree with @newmuis that bookend and sidebar must be deprecated. The endless stories experience that the amp-story-player promises is much more important from UX pov than a website wanting to have a menu or related links in stories.

In our own proprietary implementation of an endless stories UX we had to get rid of the bookend: https://visualstories.com/?app=pwa

We should make it easier for consumption platforms if we wish for AMP Stories to be adopted quickly by the big social media platforms, the likes of Fb, Twitter, etc. AMP Stories can become a great tool for websites to reach the masses through these big platforms.

We from VisualStories.com vote to deprecate both bookend and sidebar. We'll remove them from our 50k+ stories soon.