ampproject / wg-stories

Responsible for implementing and improving AMP's story format (amp-story). Facilitator: @newmuis
Creative Commons Attribution 4.0 International
28 stars 11 forks source link

wg-stories Meeting 2020-03-17 #29

Closed newmuis closed 4 years ago

newmuis commented 4 years ago

Meeting date/time (UTC)

2020-03-17 at 17:00 GMT

Instructions for joining the meeting

https://meet.google.com/ven-ztfk-esz

Agenda

Meeting Notes

TBD

Enriqe commented 4 years ago

Meeting notes

Changing Default Aspect Ratio in Desktop UI

Proposal from Paul is to make the 3 panel desktop UI default to 9:16. Biggest motivation is videos are increasingly including captions in them, needing more space for them to not be cut off.

We have some concerns about communications regarding this change. Making this change does not mean it’s not going to be cut-off in any other environment. Other platforms could still see content being cut off.

3 approaches show as many pixels of the video as possible show as many pixels of the video as possible. Show “safe area” in tooling

Charles: most clients’ videos are 16:9. Which is what most professionals shoot videos in. Problem in 9:16 is that it’s cropping a lot of the original 16:9 video. Someone has to crop the video to the point of interest. And then re-crop again to fit the 9:16 ratio.

What I like about the 3:5 (9:15) is that we can reduce the amount of cropping an original video and that it conserves more pixels of the original video.

I’m worried about the implicit recommendation by changing the default UI in the 3 panel desktop, a lot of users still prefer smaller screens.

Varun: Proposal is to make a clear distinction for creators of the “safe area” and “extra pixels” that could still be used at the tooling level.

Dima: give the option of snapping to 9:15 or 9:16 aspect ratio. Problem is where would they match. Because we don’t know that.

Charles: I see this as two separate problems (1) people relying too much on the 3 desktop UI, this can be addressed by using the amp-story-player for previewing the story at the tooling level (2) captions: we could use some other tools like automatic captioning, instead of baking the captions in the video. Should we focus the effort there instead?

Varun: We agree with you. I do think aspect ratio is important. Creators should know that what they see in the desktop UI will be different than what’s rendered in the phone. We’ll put together a proposal on how to address this.

Summary:

  1. Even with a 3:5 ratio, this ratio is not what people will see in their phones. If we can come up with a safe area aspect ratio that could be defined for most phones, and communicate it to publishers and tools, we should do that. We should distinguish between the ideal aspect ratio (what will be displayed on the largest devices) and the safe aspect ratio (what will reliably display on most devices).
    1. We need to consider whether this text into videos should be something prioritized, there are plenty of publishers trying to use existing assets that already have that text baked in and use it in amp stories. We have tried to make them change this with variable success.
  2. We can hold off on the discussion of what the safe area definition should be.

Bookend & Sidebar Deprecation

Concerns from deprecating the bookend. “It’s something nice to have. I am aware of the alternatives of CTA, page attachments, etc.. But it gives a space to advertise something outside of the story.”

Jon: Just to clarify we are not deprecating the concept of bookend, just the HTML tag. There are some alternatives we want to propose, like using the and building a bookend / sidebar with custom tags.

As an AI we could create examples of a sidebar/bookend using the player + custom code to create an alternative.

Jon shows demo of sidebar with player

What about a param of bookend=”no”

A troubling scenario is that publishers won’t know what to expect in the output. Such as placing credits in the bookend. This could cause some problems.

Filing a FR on Github for first-class credits support (system layer button)

Q’s

Q’s about the player

It will only hit low android devices, but on most devices made in the past 5 years you are not going to have a problem. The resource allocation is the same, no other ux. GM: we used a prototype with both iframe and Shadow DOM. It just uses a bit more memory, which is fine in any recent device.

We also recycle the number of iframes we use, so that they don't grow as more stories are added to the player.

There are general best practices (most UI have this) around animation timing, sizing, etc.. Hong might have more specific insights on this. Hong: We will need some time to see what people create and introduce some more guidelines later.

Quizzes and polls