Skip to content
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
Closed

Liveblog support #909

rudygalfi opened this issue Nov 12, 2015 · 15 comments

Comments

@rudygalfi
Copy link
Contributor

@rudygalfi 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
Copy link
Contributor

@jmadler 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.

@natcarey
Copy link

@natcarey natcarey 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
Copy link
Collaborator

@dvoytenko 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.

@natcarey
Copy link

@natcarey natcarey 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
Copy link
Collaborator

@dvoytenko 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
Copy link

@baynezy 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
Copy link
Collaborator

@dvoytenko 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
Copy link

@mterenzio 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
Copy link
Collaborator

@dvoytenko dvoytenko commented Dec 2, 2015

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

@natcarey
Copy link

@natcarey natcarey commented Dec 2, 2015

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

@baynezy
Copy link

@baynezy 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
Copy link

@baynezy 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
Copy link
Contributor

@jmadler jmadler commented Jun 25, 2016

Does amp-live-list cover this use case?

//cc @ericlindley-g, @erwinmombay

@ericlindley-g
Copy link
Contributor

@ericlindley-g 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
Copy link
Contributor

@ericlindley-g 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
Projects
amp-live-list
In Progress
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.