Closed erwinmombay closed 7 years ago
ericlindley-g
commented
8 years ago Since you're currently working on this, I'm thinking we can tentatively slot for the next milestone, but make clear somewhere what piece of the overall feature is being targeted for then.
Another option is to make a separate issue for the piece of functionality targeted, and slot that in the milestone; we can think about what's easiest
erwinmombay
commented
8 years ago @ericlindley-g i was planning to just keep this open and just tick stuff off the checklist (feel free to add items there too since i know you've been more in touch with partners etc) and not close it until all items are done.
erwinmombay
commented
8 years ago @ericlindley-g of course if you feel strongly about opening new issues i don't mind doing that at all. let me know :+1:
ericlindley-g
commented
8 years ago @erwinmombay That's what I was thinking, too—don't want to create extra work where we don't need any :) Current plan: just have this one bug for the feature; slot it for sprints to indicate that it is actively being worked on; and communicate somewhere (maybe in the bug, but not in separate bugs) what's expected for the end of each sprint. Of course, we can tweak this as we go
erwinmombay
commented
8 years ago @ericlindley-g SGTM, there will also be multiple PR's etc so i will probably convey work expectations either there or bring that info back here. (most likely the latter since the PR's can be closed etc and can get lost).
cramforce
commented
8 years ago @erwinmombay Feel free to publish the doc. Let Karen do a quick review.
erwinmombay
commented
8 years ago documentation here https://github.com/ampproject/amphtml/pull/3335
erwinmombay
commented
8 years ago disabled property here https://github.com/ampproject/amphtml/pull/3369
jaygray0919
commented
8 years ago Please put me on your beta-test list when appropriate. We're holding off converting our blogs to a conventional AMP structure in favor of using the new AMP elements.
ericlindley-g
commented
8 years ago Good timing—though the feature isn't 100% finished, we're hoping publishers can start testing the component. You shouldn't use amp-live-list in production until the component itself is officially pushed to prod (it won't work for any user not opted into the experiment), but it's available now as an experiment to gather feedback.
You can find documentation about how to implement amp-live-list here, and information about how to opt-in to the experiment for testing here (to test locally, you can toggle the experiment on by entering AMP.toggleExperiment('amp-live-list') into your browser's javascript console).
devongovett
commented
8 years ago Is it possible to have an amp-live-list poll a different url than the page url? We provide liveblogging software to many third parties (e.g. CNN, Fox News, etc.), and they want to support amp. Since we are providing the content, our customers will not have the content directly on their amp pages, so we need a way to have amp update using content from our servers rather than the customers. We can run a server containing amp markup for the items within a liveblog, but the customer needs to host the surrounding content on the rest of the page.
ericlindley-g
commented
8 years ago That's a promising idea. In thinking through the advantage of this approach I see it as a way to have the simple markup of amp-iframe with the UI flexibility of amp-live-list.
I imagine we would have to make sure that the target url for polling is also valid AMP, to make sure the page doesn't break or introduce any security risks on updates.
Another factor to consider is that, in this model, the primary content for the page would be pulled in from another URL. This means that we may want to require a placeholder, or make sure the component isn't within the first viewport, to ensure good UX (that the content has arrived by the time the user is looking for it).
One last thing to consider would be pagination, so users could see additional content after the max-items-per-page number is exceeded. Maybe this could be done if the publisher hosts one main live blog page, and has a dynamically generated "archive" page (e.g. "publisher.com/live-blog-page?page=7"), containing an amp-live-list that is itself configured to poll the URL of a dynamically generated page (e.g. "polling-url.com/live-blog-content?page=7")
@erwinmombay, what do you think? Maybe the developer implementation of the suggested mechanic could be an amp-live-list tag with an additional 'polling-url="pollingurl.com/live-blog-content"' attribute, and no children except the update button?
ericlindley-g
commented
8 years ago FYI to all the folks on this thread—we posted recently about the beta release of amp-live-list on the AMP Project blog. Please give it a try in development and let us know what you think! (this is the best time for feedback, before we push it to production)
And to walk through the options available, for developers thinking about the potential paths:
Option 1: When amp-live-list is available in production publishers can just wrap live-updating content in the component and its children, and publish the page (and re-publish the page in this manner when new content is available).
Option 1a: If a publisher is using a live blogging platform's API to pull in updates, they could conceivably use amp-live-list in conjunction with the API by wrapping the content returned by the API in amp-live-list before publishing. A live blogging platform could optimize this by giving an option for publishers to request content wrapped in amp-live-list already, via their API. I'd be curious to hear feedback from live blogging platform providers like you, @devongovett , on this general approach.
Option 2: Publishers can use amp-iframe to show live blogs (including iframed or javascript embeds) hosted on another page inside of an iframe. Drawbacks here are that the iframe will load later than the rest of the page, and the UI (like a floating "updates available" button) couldn't appear outside of the iframe itself.
Option 3: Publishers can publish their live blogs as static pages. Though the work to just wrap those static updates in amp-live-list is trivial at that point, so I would recommend doing that extra work and having a real "live" blog when amp-live-list is available : )
devongovett
commented
8 years ago Option 1a: The publisher could do a server side include in their amp page, wrapping content returned from our API in an amp-live-list. The problem with this approach is that the cache ttl on the amp page might be too long, and the publisher may use server side caching layers as well. With realtime updates, a ttl of even 5 minutes is too long.
Option 2. You mentioned several drawbacks to the amp-iframe approach already, but another one is that the liveblog is often the main content of the page, and amp-iframes must appear outside the initial viewport currently if my understanding is correct.
Option 3: Same drawbacks as option 1, plus no real-time updates.
Ideally we'd like to combine option 1a with polling updates directly to our servers, so the publisher would do a server side include with the initial content to get it on the screen quickly, but live updates would come directly from our backend rather than the publisher's.
ericlindley-g
commented
8 years ago @devongovett Sending polling updates directly to your servers is an interesting idea—though there would need to be some way to ensure that the response contains only valid AMP (currently this assurance happens automatically via caching). One option would be to run the content through validation on the fly, but that may not scale @erwinmombay @dvoytenko — do you have any thoughts on this?
dvoytenko
commented
8 years ago This is definitely something to think about in a bit more detail. But few quick comments:
amp-iframes must appear outside the initial viewport currently if my understanding is correct
No. Iframes can be in the initial viewport as long as they provide the placeholder. The goal there is simply avoid the page looking blank and provide visual indication that something important will appear.
So, I've been trying to find some live-blog examples and so far found a few, such as this one: http://www.cbssports.com/olympics/news/rio-olympics-2016-michael-phelps-says-goodbye-on-emotional-night-with-gold/
All the ones I've seen were based on iframes. They look pretty cool. I'm a bit concerned about nested scrolling, but I think it's generally justifiable in this case.
Can you send some of your current example articles for us to get a better idea how you approach your integrations?
dvoytenko
commented
8 years ago /cc @cramforce
cramforce
commented
8 years ago It seems reasonable to poll a different URL, but I think the better approach if the publishers just integrate on the server side.
In any case, we do not directly talk to that URL when loading from the AMP cache, so those URLs must produce valid AMP docs and be retrievable (and cacheable) on the AMP caches.
rbp15
commented
8 years ago @dvoytenko Double scrolling on a page is never justifiable. It is a bad user experience. This article from the Baynard Institute says it well. http://baymard.com/blog/inline-scroll-areas
I think the issue I'm having here is that neither Live List or Live Blog are actually live or updating incrementally. It seems that they are just general content that is compared against a cache at a regular interval and the whole page is updated.
So it's hard to pitch this as a live blogging experience to the content provider as it disregards an entire ecosystem of martech products aimed at live blogging.
Semantics (call it live content instead) aside the ask I have is the same -- I need a way to pull in JSON data from an endpoint and populate an AMP component. It could use normal attributes as a sort of templating engine.
Pseudo: [amp-live-blog-real id="myliveblog" polInterval="600" autorefresh="true" endpoint="myjsonservice"]
{{for each entry in myliveblog.entries}}
[blog entry meta1="{{entry.meta1}}" meta2="{{entry.meta2}}"][end blog entry]
{{ end for }}
[/amp-live-blog-real]
That was really ghetto but don't have much time while writing this.
This would give AMP control over the display even into the new content.
Thoughts? I just want to make sure we avoid a "developer" mindset here and welcome the experience of the user who would double scroll (scroll treadmill) and the publisher who has an established time tested (years) method for distributing content.
cramforce
commented
8 years ago Agree, double scrolling sucks, but amp-live-list never triggers that.
It does not update the whole page. It diffs the page and includes new entries into the page. Seems like ideal UX. If anything is missing it can be added, of course.
rbp15
commented
8 years ago Sorry my comment was about calling an html page on a different domain that contained the third party embed code in order to support other vendors instead of the amp component. Will add this clarification to my comment. Thank you for replying! :)
cramforce
commented
8 years ago It seems it is best for users when the content is directly embedded into the served doc.
What is the primary value provided by 3p live blogging platforms? If it is primarily the authoring tool, maybe this is a good time to invest into backend integrations that do not suffer the latency issues of client side integrations.
On Wed, Aug 31, 2016 at 4:39 PM, RP notifications@github.com wrote:
Sorry my comment was about calling an html page on a different domain that contained the third party embed code in order to support other vendors instead of the amp component. Will add this clarification to my comment. Thank you for replying! :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ampproject/amphtml/issues/2762#issuecomment-243934944, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFeT5nCsxLT2w4vAwegu_h78_ggbm4xks5qlhCugaJpZM4H8Qbg .
cramforce
commented
8 years ago I'd like to point to https://github.com/ampproject/amphtml/blob/master/DESIGN_PRINCIPLES.md#user-experience--developer-experience--ease-of-implementation In AMP we care about user experience more than about ease of integration and developer experience. If there is a user experience benefit of a frontend integration I'd love to hear it.
On Wed, Aug 31, 2016 at 5:58 PM, Malte Ubl malte.ubl@gmail.com wrote:
It seems it is best for users when the content is directly embedded into the served doc.
What is the primary value provided by 3p live blogging platforms? If it is primarily the authoring tool, maybe this is a good time to invest into backend integrations that do not suffer the latency issues of client side integrations.
On Wed, Aug 31, 2016 at 4:39 PM, RP notifications@github.com wrote:
Sorry my comment was about calling an html page on a different domain that contained the third party embed code in order to support other vendors instead of the amp component. Will add this clarification to my comment. Thank you for replying! :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ampproject/amphtml/issues/2762#issuecomment-243934944, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFeT5nCsxLT2w4vAwegu_h78_ggbm4xks5qlhCugaJpZM4H8Qbg .
devongovett
commented
8 years ago For Storify, we are moving forward with a server side integration for customers. They'll hit our API and do a server side include of an <amp-live-list> that we serve, with the content of the liveblog. As long as the Google AMP cache updates frequently enough, and the customers aren't caching on their end, that should be sufficient for us.
rbp15
commented
8 years ago @devongovett I was thinking in terms of CNN that it may be fruitful if there was a way to push content updates to AMP as in Live Search. Breaking news would be at the mercy of that cache expiry.
Also even if the server side include was faster than DOM ready would it always be? How would AMP know to wait to fire until after the server side include fired off seeing as the page would have a full DOM tree to satisfy AMP validation. If there was latency I imagine it would trigger a DOM refresh but would AMP pick that up? I'm mainly thinking of network latency to call that data from a third party. I can see some ways around it all but would be interested in hearing your thoughts.
Update:
Perhaps node middleware on the SSI call. https://github.com/tapio/live-server/issues/94
Kind of hit me like a "duh" when I read it but would still like to hear thoughts if anyone has them.
rbp15
commented
8 years ago @cramforce from that page: "Some things can be made fast and are still a terrible user experience. AMPs should deliver a fantastic user experience and speed is just one part of that. Only compromise when lack of support for something would stop AMP from being widely used and deployed."
The scope I'm talking about is a very real worldwide millions and millions of users audience. The company already has a live blogging infrastructure in place that users are used to and content writers have been trained on. It's also a lot harder at this scale to steer that change. Using an AMP component that talks to a JSON feed the principles of AMP can still be achieved and maintain a great user experience. The page paint would be incredibly fast and the user is expecting content updates at intervals -- hence it being a live blog and also hence Google already doing the polling themselves against the CDN. I believe the part about Endpoints was described as something a developer wouldn't have to do. But some of us need to do it in order to adopt this on the very real scale mentioned above. I personally believe if developers could control a JSON endpoint and consume it into valid AMP code adoption would soar in the areas this module is targeting.
Google could also have the opportunity to broker the JSON consumption should a business value be found in doing so.
cramforce
commented
8 years ago Please look into amp-list and it's limitations. It might be feasible to allow amp-live-list update using the same mechanism, but for security reasons we must severely limit the type of content that can be written from the mustache templates which may be insufficient for most live blog use cases.
I understand that re-architecting things can be daunting, but AMP (as linked to above) does not aim for the path of least resistance in terms of adoption.
@randallbpotter15 amp-list-list always works with full server side rendered page DOMs. The Nth request is the same as the N-1th request. All the server always has to do is render its most current understanding of the live content. As long as a publisher is capable of publishing a web page (which is their business) they can make them live-enabled.
rbp15
commented
8 years ago Was out sick @cramforce. Thank you for the response. Will look into amp-list and compare with amp-live-list to the end you described.
Good to know about the server side renders too :)
adelinamart
commented
7 years ago What's the status of this? Thanks.
erwinmombay
commented
7 years ago this is still in progress
rudygalfi
commented
7 years ago @ericlindley-g Might be nice to move remaining items into a project for tracking
ericlindley-g
commented
7 years ago Agreed— @erwinmombay, what do you want to preserve from this issue? We could either bump those out to a single issue w/ checklist, or separate issues as needed, and close this when they're tracked elsewhere. (I'll also do a sweep to make sure we're capturing the needs expressed in the thread, as well)
dvoytenko
commented
7 years ago Let's fan out the remaining issues and close this one since officially launch has been done.
erwinmombay
commented
7 years ago @ericfs dont see anything i want to preserve that's already not in another issue
progress
trimmed down copy of @cramforce 's original design document (will be provided here if its public, or will copy verbatim if thats easier)
overview
special form of web article which get constantly updated as a story evolves, with new elements typically being added to the front of the article.
implementation
component polls against the document itself wherein the response can either be the full document or a fragment (with a smart server). This means within the cdn the response will always have been validated.
amp-live-list must and its direct children must have a unique id as this is the basis of filtering new updates, some additional attribute will allow is to be smarter or have more functionality.
attributes
direct children attributes