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

Liveblog support #909

Closed
rudygalfi opened this Issue Nov 12, 2015 · 15 comments

Comments

Projects
8 participants
@rudygalfi
Contributor

rudygalfi commented Nov 12, 2015

I see a few paths to explore:

  • Embedding through amp-iframe or (eventually) amp-click-to-play
  • Potentially using amp-template with some modifications and/or wrapped in another component (that would handle the updating)
  • New extended components built by liveblog platform providers
@jmadler

This comment has been minimized.

Show comment
Hide comment
@jmadler

jmadler Nov 12, 2015

Contributor

In my mind, a Live Blog, as represented in AMP, would be a static AMP doc using the LiveBlogPosting markup, and an tag to pull new data.

After each new post, the document should be updated by the CMS to include the update in the body of the document, as well as the new BlogPosting data as children of the LiveBlogPosting structured data.

In order to maintain the freshness of the document following initial load, an tag, with a new "update" attribute, will continuously fetch new material for the document.

<amp-template data="https://example.com/liveblogs/2015/01-10-flight.json update="true">
    <div class="blogpost">
    {{#tweetid}}
            <amp-tweet id="{{tweetid}}"></amp-tweet>
    {{/tweetid}}
        {{#image}}
            <amp-img src="{{image}}" alt="{{text}"></amp-img>
    {{/image}}
        {{#video}}
            <amp-video src="{{video}" alt="{{text}}"></amp-video>
    {{/video}}
        {{text}}
    </div>
</amp-template>

One noted issue is that the Mustache.js syntax makes variable types unwieldy.

Contributor

jmadler commented Nov 12, 2015

In my mind, a Live Blog, as represented in AMP, would be a static AMP doc using the LiveBlogPosting markup, and an tag to pull new data.

After each new post, the document should be updated by the CMS to include the update in the body of the document, as well as the new BlogPosting data as children of the LiveBlogPosting structured data.

In order to maintain the freshness of the document following initial load, an tag, with a new "update" attribute, will continuously fetch new material for the document.

<amp-template data="https://example.com/liveblogs/2015/01-10-flight.json update="true">
    <div class="blogpost">
    {{#tweetid}}
            <amp-tweet id="{{tweetid}}"></amp-tweet>
    {{/tweetid}}
        {{#image}}
            <amp-img src="{{image}}" alt="{{text}"></amp-img>
    {{/image}}
        {{#video}}
            <amp-video src="{{video}" alt="{{text}}"></amp-video>
    {{/video}}
        {{text}}
    </div>
</amp-template>

One noted issue is that the Mustache.js syntax makes variable types unwieldy.

@matcarey

This comment has been minimized.

Show comment
Hide comment
@matcarey

matcarey Nov 24, 2015

Could this be a feature of https://github.com/ampproject/amphtml/tree/master/extensions/amp-mustache e.g. <amp-mustache update-interval=30></amp-mustache> or <amp-mustache auto-refresh delay=30></amp-mustache>.

Polling is easier to build and more annoying to use, pushing/websockets would be significantly more difficult to specify/build but should be significantly more pleasant to use. Long-polling support is a half-way point IMHO. Should we look to support auto-refresh behaviour as a precursor to a more useful solution? Some content providers would prefer to use auto-refresh so I can see it being a useful thing to support long-term. @dvoytenko - you seem to own that extension, do you have an opinion?

matcarey commented Nov 24, 2015

Could this be a feature of https://github.com/ampproject/amphtml/tree/master/extensions/amp-mustache e.g. <amp-mustache update-interval=30></amp-mustache> or <amp-mustache auto-refresh delay=30></amp-mustache>.

Polling is easier to build and more annoying to use, pushing/websockets would be significantly more difficult to specify/build but should be significantly more pleasant to use. Long-polling support is a half-way point IMHO. Should we look to support auto-refresh behaviour as a precursor to a more useful solution? Some content providers would prefer to use auto-refresh so I can see it being a useful thing to support long-term. @dvoytenko - you seem to own that extension, do you have an opinion?

@dvoytenko

This comment has been minimized.

Show comment
Hide comment
@dvoytenko

dvoytenko Nov 24, 2015

Collaborator

@matcarey It won't be amp-mustache itself, but rather another extension. amp-mustache or any other type of template cannot render itself. But any other component can do rendering using templates. One such example is the amp-list component. Here, I imagine something like:

<amp-to-be-named update-interval=30>
  <template type="amp-mustache">
    <div class=blogpost>
      {{...}}
    </div>
  </template>
</amp-to-be-named>

As far as autorefresh concerned - my big preference would be for some sort of alert that new data is available and refresh itself done via user action. E.g. tap on the alert. But that's obviously TBD.

Collaborator

dvoytenko commented Nov 24, 2015

@matcarey It won't be amp-mustache itself, but rather another extension. amp-mustache or any other type of template cannot render itself. But any other component can do rendering using templates. One such example is the amp-list component. Here, I imagine something like:

<amp-to-be-named update-interval=30>
  <template type="amp-mustache">
    <div class=blogpost>
      {{...}}
    </div>
  </template>
</amp-to-be-named>

As far as autorefresh concerned - my big preference would be for some sort of alert that new data is available and refresh itself done via user action. E.g. tap on the alert. But that's obviously TBD.

@matcarey

This comment has been minimized.

Show comment
Hide comment
@matcarey

matcarey Nov 26, 2015

This is something I'd like to take a look at, it's a feature the client I'm working with would like to use and has invested in on different platforms. I'd look to follow the shape that @dvoytenko has specified. The implementation looks like it's going to be relatively similar to https://github.com/ampproject/amphtml/tree/master/extensions/amp-list

I'd be perfectly happy to work with others or alone on this but I wouldn't want to duplicate/waste effort (mine or other people's) - is there anyone already working on implementing this feature? Is there anything that would put us off adding this feature?

Initial version would be only polling on an interval - it's the easiest to build, the least controversial, easiest to host & serve via CDN. I'd expect this to support long-polling AJAX and therefore the interval would be a delay between the end of rendering and the start of the next AJAX request and I wouldn't implement my own timeout.

Once we have that in place I'd like to discuss 'better' implementations, I imagine that things like websockets are going to lead to a better UX but be more controversial & harder to specify to everyone's needs.

matcarey commented Nov 26, 2015

This is something I'd like to take a look at, it's a feature the client I'm working with would like to use and has invested in on different platforms. I'd look to follow the shape that @dvoytenko has specified. The implementation looks like it's going to be relatively similar to https://github.com/ampproject/amphtml/tree/master/extensions/amp-list

I'd be perfectly happy to work with others or alone on this but I wouldn't want to duplicate/waste effort (mine or other people's) - is there anyone already working on implementing this feature? Is there anything that would put us off adding this feature?

Initial version would be only polling on an interval - it's the easiest to build, the least controversial, easiest to host & serve via CDN. I'd expect this to support long-polling AJAX and therefore the interval would be a delay between the end of rendering and the start of the next AJAX request and I wouldn't implement my own timeout.

Once we have that in place I'd like to discuss 'better' implementations, I imagine that things like websockets are going to lead to a better UX but be more controversial & harder to specify to everyone's needs.

@dvoytenko

This comment has been minimized.

Show comment
Hide comment
@dvoytenko

dvoytenko Nov 27, 2015

Collaborator

@matcarey No one works on this right at this moment. Let's discuss on Monday how we can go about it? I'm confident that we can start with some basic polling scenario and improve it. What are your thoughts on the protocol that AJAX call return?

Personally, I'm more concerned with user flow of this experience. E.g. avoiding page resizing and unexpected shuffles of UI, especially as the reader might be reading something else or scrolling. Obviously fixable with a good UX, but what are your thoughts on this?

Collaborator

dvoytenko commented Nov 27, 2015

@matcarey No one works on this right at this moment. Let's discuss on Monday how we can go about it? I'm confident that we can start with some basic polling scenario and improve it. What are your thoughts on the protocol that AJAX call return?

Personally, I'm more concerned with user flow of this experience. E.g. avoiding page resizing and unexpected shuffles of UI, especially as the reader might be reading something else or scrolling. Obviously fixable with a good UX, but what are your thoughts on this?

@baynezy

This comment has been minimized.

Show comment
Hide comment
@baynezy

baynezy Dec 1, 2015

@dvoytenko what is your resistance to using an established push technology rather than polling? Sever-Sent Events, for example, would work with the syntax that @jmadler suggested and would allow near-instant updating.

baynezy commented Dec 1, 2015

@dvoytenko what is your resistance to using an established push technology rather than polling? Sever-Sent Events, for example, would work with the syntax that @jmadler suggested and would allow near-instant updating.

@dvoytenko

This comment has been minimized.

Show comment
Hide comment
@dvoytenko

dvoytenko Dec 1, 2015

Collaborator

@baynezy I was intending to say that most of my concerns are after the update signal has been received. Long polling doesn't seem like a bad choice given that it's more or less universal and would likely be part of the final solution anyway. But what do you have in mind for an established push technology? We can go straight to websockets but then we will need to immediately come up with the fallback protocol. If we use an existing one, we'd need to see which one is the simplest to integrate on backends.

Collaborator

dvoytenko commented Dec 1, 2015

@baynezy I was intending to say that most of my concerns are after the update signal has been received. Long polling doesn't seem like a bad choice given that it's more or less universal and would likely be part of the final solution anyway. But what do you have in mind for an established push technology? We can go straight to websockets but then we will need to immediately come up with the fallback protocol. If we use an existing one, we'd need to see which one is the simplest to integrate on backends.

@mterenzio

This comment has been minimized.

Show comment
Hide comment
@mterenzio

mterenzio Dec 1, 2015

In addition to:

{{...}}

might not there also be something like:

Upon clicking would update the mustache template with the new data.

Values for action might be "append", "prepend", "replace"

On Tue, Dec 1, 2015 at 11:55 AM, Dima Voytenko notifications@github.com
wrote:

@baynezy https://github.com/baynezy I was intending to say that most of
my concerns are after the update signal has been received. Long polling
doesn't seem like a bad choice given that it's more or less universal and
would likely be part of the final solution anyway. But what do you have in
mind for an established push technology? We can go straight to websockets
but then we will need to immediately come up with the fallback protocol. If
we use an existing one, we'd need to see which one is the simplest to
integrate on backends.


Reply to this email directly or view it on GitHub
#909 (comment).

mterenzio commented Dec 1, 2015

In addition to:

{{...}}

might not there also be something like:

Upon clicking would update the mustache template with the new data.

Values for action might be "append", "prepend", "replace"

On Tue, Dec 1, 2015 at 11:55 AM, Dima Voytenko notifications@github.com
wrote:

@baynezy https://github.com/baynezy I was intending to say that most of
my concerns are after the update signal has been received. Long polling
doesn't seem like a bad choice given that it's more or less universal and
would likely be part of the final solution anyway. But what do you have in
mind for an established push technology? We can go straight to websockets
but then we will need to immediately come up with the fallback protocol. If
we use an existing one, we'd need to see which one is the simplest to
integrate on backends.


Reply to this email directly or view it on GitHub
#909 (comment).

@dvoytenko

This comment has been minimized.

Show comment
Hide comment
@dvoytenko

dvoytenko Dec 2, 2015

Collaborator

@matcarey feel free to ping us at any time on slack if you'd like to discuss any details.

Collaborator

dvoytenko commented Dec 2, 2015

@matcarey feel free to ping us at any time on slack if you'd like to discuss any details.

@matcarey

This comment has been minimized.

Show comment
Hide comment
@matcarey

matcarey Dec 2, 2015

Thanks, I've just signed up and started a chat.

matcarey commented Dec 2, 2015

Thanks, I've just signed up and started a chat.

@baynezy

This comment has been minimized.

Show comment
Hide comment
@baynezy

baynezy Dec 8, 2015

@dvoytenko I really like Server-Sent Events as it is standard HTTP and you can fall back to long polling using a polyfill if necessary. I prefer solutions that embrace standards.

baynezy commented Dec 8, 2015

@dvoytenko I really like Server-Sent Events as it is standard HTTP and you can fall back to long polling using a polyfill if necessary. I prefer solutions that embrace standards.

@baynezy

This comment has been minimized.

Show comment
Hide comment
@baynezy

baynezy Jan 20, 2016

@dvoytenko as a follow up to this I wanted to clarify my stance.

Long polling a JSON end point feels like a fall-back for when something more useful is not supported. So I would rather that we followed an agreed standard for a supported real-time implementation. Then use long-polling as a fall-back/polyfill for older browsers.

baynezy commented Jan 20, 2016

@dvoytenko as a follow up to this I wanted to clarify my stance.

Long polling a JSON end point feels like a fall-back for when something more useful is not supported. So I would rather that we followed an agreed standard for a supported real-time implementation. Then use long-polling as a fall-back/polyfill for older browsers.

@rudygalfi rudygalfi added the Needs UX label Jan 23, 2016

@rudygalfi rudygalfi added this to the M2 milestone Jan 30, 2016

@rudygalfi rudygalfi modified the milestones: M2, Backlog Mar 4, 2016

@jmadler

This comment has been minimized.

Show comment
Hide comment
@jmadler

jmadler Jun 25, 2016

Contributor

Does amp-live-list cover this use case?

//cc @ericlindley-g, @erwinmombay

Contributor

jmadler commented Jun 25, 2016

Does amp-live-list cover this use case?

//cc @ericlindley-g, @erwinmombay

@ericlindley-g

This comment has been minimized.

Show comment
Hide comment
@ericlindley-g

ericlindley-g Jun 25, 2016

Collaborator

Yes—thanks for pinging this thread. amp-live-list covers the live blog use case for instances that aren't a third-party widget (which in most cases can just be shown in amp-iframe)

Collaborator

ericlindley-g commented Jun 25, 2016

Yes—thanks for pinging this thread. amp-live-list covers the live blog use case for instances that aren't a third-party widget (which in most cases can just be shown in amp-iframe)

@ericlindley-g

This comment has been minimized.

Show comment
Hide comment
@ericlindley-g

ericlindley-g Feb 3, 2017

Collaborator

Closing this, since amp-live-list covers the use-case, but folks in the thread should feel free to file feature requests and bugs for anything not yet solved!

Collaborator

ericlindley-g commented Feb 3, 2017

Closing this, since amp-live-list covers the use-case, but folks in the thread should feel free to file feature requests and bugs for anything not yet solved!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment