This proposed amp-disqus component would embed Disqus comments inside an iframe.
There is a demo page of this embed here: http://northisup.github.io/disqusamp/amp-demo/
The demo loads a lightweight non-interactive iframe with the top comments of the thread, along with a "Read Discussion" button which opens the fully interactive comments in a new window.
As an amp component, it could be embedded like this:
<amp-disqus
height="400"
data-shortname="northisup"
data-identifier="/amp-demo/"
data-url="http://northisup.github.io/disqusamp/amp-demo/">
</amp-disqus>
The data- attributes would match the configuration options set for the existing embed via disqus_config. data-shortname is required to identify the publisher. data-identifier and data-url would be recommended to identify the discussion thread. If omitted, some attributes (ex. data-url and data-title) would be automatically determined from the container page, at the risk that implicit page identification creates duplicate discussion threads.
/cc @dvoytenko
/cc @cramforce
If this is not interactive, could it be done as a server side integration instead?
Providing an easy to integrate commenting experience is the core product that Disqus offers. Over the last several years we have investigated several options, including server side integrations, and found that publishers find them too difficult to use. Server side integrations shift much of the technical burden from Disqus to the publishers, such as managing page cacheability against having up to date comments.
I understand that. One of AMP's core goal is to say: We have erred too much on the side of easy integration that are good for publishers in term of integration time, but bad for users and this got us into the mess we are in.
We have a chance to re-evaluate these decisions.
Could the AMP tag be configured with a URL that can be optionally statically discovered server side included, so sophisticated publishers can do the right thing?
E.g.
<amp-disqus-comments src="https://disqus.com/api/amp?url=http://northisup.github.io/disqusamp/amp-demo/"></amp-disqus-comments>
Then somebody could build a simple server that looks for amp-disqus-comments[src], fetches the URL and replaces the element with the response.
Sure, but isn't this true of many of the currently approved widgets? Also we intend to keep iterating and add interactivity to the widget.
We're trying to work with widgets were a move to a better model is realistic. E.g. Twitter. A good way to add interactivity is by having all buttons open popups (like Twitter's widget does). That also effectively combats click jacking, so is desirable for other reasons.
I think its worth really discussing what the right way to do this is. I've seen many sites tending towards hiding all comments behind a click. I think we should make that easy / the default. When the iframe only loads on click we can be less sensitive about its weight.
I'd definitely look for an option where comments are hidden behind the click on "See comments" button. If we want to improve engagement, I think we can always explore things like putting number of comments in the button (e.g. "See comments (24)") or similar.
Thanks to everyone for the feedback. Circling back on this after some internal discussion, just wanted to update everyone that we're going to move forward with a client-side integration as opposed to the iframe approach we initially mentioned.
Awesome! Looking forward to the PR!
PR closed here. Anything else needed to be done here?
@adelinamart - As Disqus, we are not planning to pursue an official AMP component right now. That said in case there are other people interested in implementing, I think the issue should remain open.
@rudygalfi to see if this can be prioritized as a new FR
We have no plans on our end to prioritize this (we would likely need help form Disqus in that event anyway). I'll close this until someone is ready to work on it.
Most helpful comment
Thanks to everyone for the feedback. Circling back on this after some internal discussion, just wanted to update everyone that we're going to move forward with a client-side integration as opposed to the iframe approach we initially mentioned.