AMP Implementation as an 'Article Type'

[Niv Froehlich]

Just a quick note, I'd like to keep the focus whether or not, the best implementation for AMP would be as 'Article Type'

(i.e. I am politely asking that we continue discussions on the merits of AMP  adoption (and entirely different discussion) on the the thread, "Is Joomla joining Google's AMP Project").


AMP Implementation as an 'Article Type'

I'd like to suggest, and have a discussion on the implementation of AMP as an 'Article Type'

1. From a usability point of view, this seems to be a good fit.  When you are drafting an article, you select AMP Article.'  Form the user's perspective, this keep things simple.

2. Modules could be added by 'Article Type.'

3. We would need a way to check, or denote, module compliancy for AMP pages, so that a user would know which modules they can, or cannot include, in an AMP article (as not all modules will be AMP compliant).

I would like to see that non-compliant modules are permitted, but that there is

a) a warning to the user; and

b) a way in which the Joomla CMS can quickly identify which AMP modules are compliant.
 
4. AMP specific options can be added to the Article Options (i.e. AMP articles must contain a <link rel="canonical" href="$SOME_URL" /> tag inside their head that points to the regular HTML version) - so, as an example, it would make sense in UI to be able to link to the regular HTML version would make sense.

From a usability perspective, I think this would be the obvious way to incorporate AMP capabilities in Joomla.  Please let me know your thoughts.

Cheers,

Niv

[Michael Babker]

This doesn't look like an "Article Type" to me at a glance, but rather a full page builder, which is a vastly different type of composition than what any of the existing core infrastructure offers today.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Michael Babker]

Just to add too, again going back to how the spec presents itself to me and the live demos I've seen thus far, I don't believe that in the context of an AMP page modules are going to be appropriate here.  Your suggestions to me imply a media rich mobile page which has all features available to it and with AMP's focus on page speed and the primary content section of the relevant canonical page, modules look to be extra "fluff" that would actually hurt AMP page composition and speed.

On Sat, Nov 21, 2015 at 10:58 AM, Niv Froehlich <nivs...@gmail.com> wrote:

--

[kisswebdesign]

Initially I liked the idea, however, from what I've read AMP is an all or nothing decision.

I mean, it is the whole page that is compliant or don't bother because you won't get the benefits.

Having the article type as AMP would need the menu to have an AMP version (your nice jQuery megamenu will not be allowed) - who produces that, the designer, the menu module provider, or is it dynamically adjusted to be AMP compliant if the main article type is set to AMP?.

The cookie warning you show to EU visitors runs custom JS, that will have to go and you'll need a different solution (this point applies to any AMP page, not just for this discussion).

The nice footer will need an AMP version too, especially as your Cookie policy will need to be linked to now you don't have that JS popup. Does this mean different content between the HTML and the AMP page?

You might need to rethink the side bar (ads? only if you use one of the providers that has AMP compliant serving), or that small company you have affiliate links (ad, banner, custom module,etc) that is not AMP compliant - gonna have to rethink that too.

Who will produce these AMP compliant modules, and how will they be identified (by a flag that the module producer sets, or by active scanning, or other)?

Pity really, as the article is usually the important part of the page, the rest is just 'nice to have' decoration and adverts, lol.

So every page, or menu route, would need to be manually configured with 2 sets of options - one for AMP and one for standards compliant HTML.

Not every user will be able to make the decisions needed in a fully informed way regarding which modules can/should be included in the AMP page. Warning, the module "menu" is not AMP compliant - [ ] use anyway; [ ] Do not show on AMP pages.
And then you have a page without a menu, because the user didn't fully understand the implications of the decision.

Or does setting "AMP" as the type for the module apply some pre-display processing to change the modules to be AMP compliant (removing some content that doesn't comply)?

I also think there would need to be a "view full site" link on every page, to give the visitor the choice to see the "real" page instead of the AMP one.

So, finally, nice idea but I don't think it would be a suitable solution.

[Niv Froehlich]

@kisswebdesign

I mean, it is the whole page that is compliant or don't bother because you won't get the benefits.

You will get some benefits in the way of speed performance improvements, but you won't get an AMP Compliant page, and our goal is to produce AMP compliant pages.

 

Having the article type as AMP would need the menu to have an AMP version (your nice jQuery megamenu will not be allowed) - who produces that, the designer, the menu module provider, or is it dynamically adjusted to be AMP compliant if the main article type is set to AMP?

jQuery is not permitted.   There is yet no convention, component, or guidance from Google as to how to handle menus.  (This should form part of the questions for the Joomla AMP team to forward to the AMP Project liaison). 

The cookie warning you show to EU visitors runs custom JS, that will have to go and you'll need a different solution (this point applies to any AMP page, not just for this discussion).

Again, a great question for the AMP Project liaison (I will add it to the compiled list of questions which Jessica has asked for). 

 

You might need to rethink the side bar (ads? only if you use one of the providers that has AMP compliant serving), or that small company you have affiliate links (ad, banner, custom module,etc) that is not AMP compliant - gonna have to rethink that too.

Yes.  This is part of Google's motive in introducing AMP - the want to 'force' content producers to eliminate anything that makes a web page 'sluggish.'

I found this article to be very informative in that respect 

Many questions about Google's AMP (Accelerated Mobile Pages)

Here are some of the meeting minute notes from the October 2015 when Google convened during the unconference about AMP

http://www.w3.org/2015/10/28-amp-minutes (here's an expert, I'll give you the gist)

<jeff_> Chris: THe focus is on AMP because speed is hard to define

<jeff_> ... page load time? - just one metric

<jeff_> ... hard to teach people to design for speed

<jeff_> ... we give dev tools, pattern, but not the only tactic.

<jeff_> Alex: Easy to screw-up scrolling performance, layout, resource loading, network, etc.

<jeff_> ... bumper bowling.

Two points here.

- The view is that easy for the average person to screw up page performance (i.e. hard to teach people to design for speed)

- Therefore, AMP takes the 'bumper bowling' approach (meaning, 'Let's make this foolproof') for content producers to make their pages performance optimized.

I think that, as a CMS, if we are going to embrace AMP, finding a way to make pages AMP compliant 'foolproof' would be inline with the whole reason behind adopting AMP.

You might need to rethink the side bar (ads? only if you use one of the providers that has AMP compliant serving), or that small company you have affiliate links (ad, banner, custom module,etc) that is not AMP compliant - gonna have to rethink that too.

That is core to the philosophy of the AMP project.   AMP has dedicated a lot of time and resources to working with ad networks to speed up delivery time and eliminate jank.

see https://www.ampproject.org/how-it-works/

Consumption of news articles, and similar relatively static content, is often painfully slow, with pages taking a long time to load. Even after text becomes visible, pages continue to build up over many seconds, as ads and images come into display. The result is an often jarring experience of janky scrolling and users needlessly losing their reading position.

In other words, a 'rethink' of adverts is part of the core ambitions of the AMP Project.

Pity really, as the article is usually the important part of the page, the rest is just 'nice to have' decoration and adverts, lol.

That's exactly the point.  All these 'nice to haves' slow down pages.

Keep in mind that the specification assumes (although does not make it necessary) that there will be "regular HTML page" and even incorporates a mandatory tag for it

AMP Required Markup

see https://github.com/ampproject/amphtml/blob/master/docs/create_page.md

contain a <link rel="canonical" href="$SOME_URL" /> tag inside their head that points to the regular HTML version of the AMP HTML document or to itself if no such HTML version exists.

So by this, it is understood that web sites (which want to rank well on Google mobile searches) should have 1) an AMP page; and 2) the Regular HTML page.  

The best-practice, therefore, would be to put the 'niceties' on the Regular HTML page while restricting the AMP pages to the 'essential content.'

So every page, or menu route, would need to be manually configured with 2 sets of options - one for AMP and one for standards compliant HTML.

I'm still struggling with.  Still haven't figured how menus would be best handled on AMP pages (I have some ideas though - but would like to see if there is any guidance from the AMP Project on menus) as well as StackOverflow.com  (use the tag 'amp-html' to search Stack Overflow for q's and a's regarding AMP).

How to keep AMP organized, in the context of a Joomla web site, is something I'm still trying to wrap my head around.  I wonder if assigning a category for AMP pages might be the best approach.

Not every user will be able to make the decisions needed in a fully informed way regarding which modules can/should be included in the AMP page. Warning, the module "menu" is not AMP compliant - [ ] use anyway; [ ] Do not show on AMP pages.
And then you have a page without a menu, because the user didn't fully understand the implications of the decision.

Again, we have to answer the 'menu' question, but I think it would best to take the 'bumper bowling' approach.

The AMP Project itself doesn't prevent elements, JavaScript, or CSS on the basis that it slow, the AMP spec's block them on the basis that they 'could be' slow.

This is an important distinction.  

Or does setting "AMP" as the type for the module apply some pre-display processing to change the modules to be AMP compliant (removing some content that doesn't comply)?

When we get into dynamically generated content, this all get's really tricky.  2 things factor in

1) The page needs to load fast - as fast as possible; and

2) It's need to meet the AMP specs - so any module that relies on jQuery for instance, would be 'non-compliant.'

I also think there would need to be a "view full site" link on every page, to give the visitor the choice to see the "real" page instead of the AMP one.

Absolutely!  This is covered above, but an option in the article admin to 'Include link to Regular HTML'  can automate that process, using the <link rel="canonical" href="$SOME_URL" /> mandatory URL and generate that link in the AMP page HTML.
 

@ Michael

Your suggestions to me imply a media rich mobile page which has all features available to it and with AMP's focus on page speed and the primary content section of the relevant canonical page, modules look to be extra "fluff" that would actually hurt AMP page composition and speed.

Again, a Joomla! UX that incorporates the 'bumper bowling' approach as describe above.  Media Rich and AMP do not play nicely together, rather a 'Plain Toast' AMP page that links to the media rich page, as described above.

So, finally, nice idea but I don't think it would be a suitable solution.

Perhaps not (although I'm not ready to fully ditch discussion on this approach), but I really appreciate all the feedback and thoughts - and looking forward to hearing other ideas for AMP implementation as well!

Cheers,

N

[Niv Froehlich]

Just to add a quick note on how to handle navigation menus on AMP pages

Keeping in mind that

a) AMP pages are intended to compliment web sites (not replace them).  A regular HTML site is assumed in the standard (otherwise why would there be a mandatory element <link rel="canonical" href="$SOME_URL" / > in which spec says that if there is now regular HTML page, you need to point the page to itself?

It would be odd to write such a requirement if it was expected, as part of the AMP Project, that content publishes weren't using AMP pages as an 'add-on' to their existing Regular HTML Pages.

b) Are intended to make page loads as fast as possible.

I would suggest that the best-practice for navigation menus for AMP pages is to

a) eliminate them entirely on AMP pages and leave those to the Regular HTML version of the web site;

b) include a link on the AMP page, "Go to web site" which goes to the equivalent Regular HTML page or some other predetermined page on the Regular web site.

That's as simple, bare-bones and streamlined (performance optimized) as one can get - and it's in-line with the fundamental goals of AMP.

Best,

N

--

[Michael Babker]

You're looking for ways to do stuff that doesn't exist in the current spec (all the nice to haves).  If you want to suggest additions to the spec (navigation probably should be considered somehow, and last I looked through the open GitHub issues, they had a couple open indicating it was being discussed), I'd recommend proposing them directly to Google instead of using us as a proxy.

Not to sound rude, but right now my interest in Joomla support is based on the spec as presently written and how it evolves over time.  If navigation or rich media type elements are added to the spec, then we adjust our implementations accordingly.  Until that point though, at least for me, I'm not interested in discussing hypotheticals or coding for "what if" scenarios.

To build AMP support, I don't believe you need to expand the menu manager, module manager, or article manager in any major ways or to introduce the concept of page management in the ways you're suggesting.  At the absolute bare minimum, Joomla needs a new JDocument type for AMP and extensions will need to add view.amp.php classes for the new format (similar to the current approach with HTML, JSON, RSS, etc. in core today).  The AMP document format right now should only support the component output (because that is the primary page output and what AMP is really interested in); the nice to haves (modules, navigation, etc.) aren't part of the overall picture as of yet based on the way the specification and live demos that have been shown are set up at this time.  Again, this can change as AMP evolves.  By that approach, in the same way that you can append format=whatever to many URLs in Joomla (or if you're using format suffixes .whatever), the AMP page is requested with basically the same URI scheme as the "normal" page already uses.  Using the Developer Network as an example, https://developer.joomla.org/security-centre.html is a full HTML page for the Security Center feed and https://developer.joomla.org/security-centre.feed is its RSS feed.  No menu system magic tricks are needed to pull that off, no additional layers of configuration necessary.  In theory, the same should be possible for https://developer.joomla.org/security-centre.amp in this case.

If/When AMP adds additional items to the specification (navigation sounds very logical, but there are details to that such as what is supported such as a full menu, breadcrumbs, or pagination), we adjust the code implementation as needed.  So this would mean changes to the menu system most likely to link to AMP pages when in that context (if one is available).  Advertisements already have in-built support, so we need to look at how Joomla users are implementing that and find a workable solution to ensure those get converted to AMP (if the network is supported).  Or is it decided that isn't a Joomla core issue and the implementation details are left to the module/template authors and end users.  The same question can be asked and debated on the other components AMP supports as well.  What I suggest being careful of is having Joomla try to do everything itself for AMP or trying to automagically convert existing HTML output to AMP spec otherwise the platform ends up with a very non-performant AMP processor that hurts more than it helps.

On Sat, Nov 21, 2015 at 2:21 PM, Niv Froehlich <nivs...@gmail.com> wrote:

--

[Niv Froehlich]

@ Michael

I'd recommend proposing them directly to Google instead of using us as a proxy.

- see my last post on menus
- Jessica has asked that we prepare questions.  To quote Jessica from Nov 16

It would be great if you can gather a list of questions. They are really interested how they can make their dev materials be more clear about any concerns. Any and all suggestions are welcome. 

I have been following this request - sorry for any misunderstanding.  I understand from this that we should direct our questions to the Joomla! AMP team - did I misunderstand?

Or is it decided that isn't a Joomla core issue and the implementation details are left to the module/template authors and end users.  The same question can be asked and debated on the other components AMP supports as well.  What I suggest being careful of is having Joomla try to do everything itself for AMP or trying to automagically convert existing HTML output to AMP spec otherwise the platform ends up with a very non-performant AMP processor that hurts more than it helps.

I'd like to answer both these in one shot.

Simply, it depends on what would create the best user experience for Joomlers.

If one can click on an Article Type, put their content in, and hit publish, then we've created an awesome user experience, and IMHO, that's what we should strive for.

Conversely, if we leave this up to 3rd parties, a Joomler would have to research and find extensions, install them and hope those extensions do what they ought to do.

This would be a very negative user experience when these feature could just be built-in to the core.  Extension and Template developers can then build on top of that (i.e. including a flag for AMP compliancy) so that the Joomla CMS can detect which modules are AMP compliant. 

If/When AMP adds additional items to the specification (navigation sounds very logical, but there are details to that such as what is supported such as a full menu, breadcrumbs, or pagination), we adjust the code implementation as needed

100% agreed!  I'm for using what's already in the AMP spec, and as the AMP SDK evolves, Joomla! AMP pages incorporate those.  

So for example, if no navigation component currently exists, let's not build one, and when and if one does exist, then we can figure out how to incorporate it.

As for the current suggestion to handle, navigation, our posts crossed paths - see above on my thoughts for implementation.

Best,

Niv 

 

[Michael Babker]

I'll leave the questions thing up to others to debate, but the way I'd handle it is if it relates explicitly to Joomla's implementation it's something that should be fielded through Joomla's team.  If it's general commentary on the AMP project (spec recommendations, documentation requests, etc.), it doesn't need to be handled by proxy.  So for me, implementation details about how Joomla deals with navigation in AMP pages belongs here and questions about what Joomla should do about that (best practices, etc.) stay here as well.  But proposing changes to the spec (adding new components), requests for additional general documentation, and things along that nature that start to get out of scope for Joomla specifically would be better suited to communicate directly with the AMP team via their GitHub repo about.  That's just my personal opinion.

Your Article Type idea to me simply isn't just an "article type" or even a content type (think components in general now).  Rather, the way I'm seeing it, you're getting into a full page builder scenario.  Unless AMP really starts to compete with full stack CSS frameworks and allows all the features that are already used today, that's just overengineering things.  That might be a feasible workflow suggestion in general for future CMS versions, but it's not a requirement for AMP at this point.  At the user level, as long as AMP pages are only dealing with content, there aren't any workflow changes needed in what the user already does.  They still manage their articles through com_content (or whatever content component(s) they use).  This does come with a tradeoff, in the approach that I'm suggesting with JDocument that a component has to support an AMP view class.  This is no different than them needing to do the same for all view formats in general, so I don't see this being an issue and likewise it enables components that could not feasibly publish useful AMP pages to opt-out in full.

Until something with the spec changes, my suggestion right now is to 100% ignore modules in AMP pages.  This is just for the initial working version.  Building out the needed infrastructure and dealing with the existing ecosystem of plugins just to ensure component content renders correctly is going to present enough challenges (i.e. plugins that don't perform context/environment checks and make changes in instances they should not be).  The infrastructure is already in place to render modules, adding that to the JDocumentAmp API is going to be pretty painless.

As for not building into Joomla everything needed to just make every extension work with AMP, frankly there is too much to consider and the processing time to do it would hurt the AMP experience unless AMP pages were always cached in a Joomla install.  Without standardized data structures, having Joomla try to convert the data or output from modules or plugins that support ads for example gets rather tricky.  Or converting all of the loaded scripts and stylesheets on a HTML page into AMP format (in the case of stylesheets taking a remote file and converting it to an inline style declaration) being another pain point to deal with.

Automattic's plugin for WordPress shows that many simple HTML elements can be converted to AMP rather easily.  Their approach also adds a generic template (similar can be done with Joomla and the system template, same logic used for error pages today).  These are items we can learn from.  Also looking at the plugin, thus far they only have support for post objects, so it does look like they are also taking the approach that extensions will have to implement custom code for different object types.  So there's a lot of resources out there to study.

[Bakual]

I agree with Michael that it doesn't make sense to ask questions to Google here. Keep things focussed on the implementation into Joomla and ask the questions targeted at Google over there.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

[Michael Babker]

There are some good questions that play into the Joomla implementation that should be asked and discussed here, like how to handle "secondary content" (modules, site header/footer content, navigation, etc.) and handling links in content (does that convert to AMP links if one is available for example).  Those are the types of things we should be seeking Google's advice on, not only for ourselves but ensuring all implementors have clear guidance.  But stuff like "I'd like to propose a navigation component" should go to Google direct.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Niv Froehlich]

@ Michael

 

But proposing changes to the spec (adding new components), requests for additional general documentation, and things along that nature that start to get out of scope for Joomla specifically would be better suited to communicate directly with the AMP team via their GitHub repo about.  That's just my personal opinion.

I think we are on the same page here.  I don't believe I proposed any changes to the spec, but just in case, considered those retracted for the purposes of Joomla/AMP implementation.

That might be a feasible workflow suggestion in general for future CMS versions, but it's not a requirement for AMP at this point.

Ha!  I'm a UX and 'Business Requirements' guy - you are the PHP/Software Architecture Master - so it's neat to see the difference in perspective.

I guess that becomes part of the Roadmap for J3!

1) there needs to be a quick and efficient pathway to implementation;

2) it would be fantastic to approach this problem, not just from 'technical implementation' (i.e. what coding changes are needed), but also from a user experience point of view (i.e. how can we make this as intuitive and easy for the end-user).

Often us UX/Business Requirements guys live a Utopia were we believe that there is an endless supply of programmer resources, who in about 45 min (with coffee breaks) can design what we envision.

:-).

I'm curious about the 'use-case' scenario (forgetting the technical requirements) but I'm hoping we can exchange our views here.

I see this as follows.

Company XYZ has an existing online publication (Joomla 3.x) with hundreds of web pages, mostly content (i.e. news articles and how-to guides).

They need to make AMP compliant pages.  They have many categories, we will "SEO Best-Practices" as the sample category.


Scenario 1

Phase 1

1. Create a new Category called AMP

2. Create a new AMP article for each corresponding regular HTML article.

3. Copy and past title, meta data and content using a AMP compliant content editor (I guess we need to hope that one is available - not sure on this )

4. Enter the article's canonical link to regular HTML page.

Phase 2 

 
This would be a future implementation.   Company XYZ wants to add modules (as examples, related articles, most recent articles)

5. Web admin/author searches existing modules/plug-ins using AMP Compliant filter

6. Modules are added (how to flag or warn user if they add non-compliant AMP modules)

Michael, can you kindly provide a proposed use-case scenario for what you envision?

This would be helpful to me as I'm uncertain what you mean by a 'page builder' approach (kindly forgive my ignorance here).

Even though a publisher may have hundreds or thousands of pages, I'm hesitant to think of trying engineer software that would automate this process - I think that would be incredibly complex and prone to errors.

@Michael and Bukual

I think we are on the same page with the Navigation - my suggestion is the best way to implement menus within the current framework and goals of AMP, not to suggest that we custom-build navigation - in fact, it's based on the assumption that no provision for navigation has been provided.

In that vain, menu navigation, on the AMP page, is quite simply handled with a 'Go to Web Site' link that utilizes the already mandatory AMP <link rel="canonical" href="$SOME_URL" /> , but open to other ideas.

The exception would be in the case that the page points to itself (part of the standard), in which case such a link 'Go to Web Site' would be redundant and therefore should not be displayed.

Is this not inline with what you suggest?

Best,

N

 

[Michael Babker]

Your phase 1 suggests that (using com_content as an example) you have separate articles for AMP content and "normal" content.  That isn't the way I'd go about it unless you are making major changes to articles for AMP.  The way I'm looking at it, you wouldn't do that.  Using Joomla's existing system to render pages in different formats, my approach uses the articles you already have and can handle converting some elements to AMP as appropriate (same as the Automattic WP plugin does with images and audio, for example).  Go back to my post where I point out how the Security Center HTML and RSS views are built.  It's that same type of approach.

At a technical level, this requires review and probably changes to most plugins.  For example, the email cloaking plugin would need to be coded if it isn't already to not use JavaScript to cloak emails on AMP pages.  And in the page break plugin, it would either need to just show the full article in one page (removing the page breaks) or reformat the TOC in a manner that is suitable for AMP.

So until menus and secondary content types get thrown into the mix, the existing user workflow doesn't change.  You manage one article and Joomla takes care of ensuring its contents get rendered correctly in a single article AMP view or as part of a RSS feed.  If the use case of making drastically different articles to represent the same content in AMP really does become a heavily demanded feature, plugins can be used to extend the relevant forms and add the extra logic needed (a field to map to the relevant canonical item for example).  I don't know how BBC has managed their implementation, but based on the WordPress plugin, I'd say having duplicated content in your backend for AMP vs normal HTML shouldn't happen.

- Michael

Please pardon any errors, this message was sent from my iPhone.

[Niv Froehlich]

You manage one article and Joomla takes care of ensuring its contents get rendered correctly in a single article AMP view or as part of a RSS feed.

I see at least the following challenges

- there is such a range of native plug-ins, 3rd party extensions including a whole range whose modules rely non-compliant (AMP) JavaScript and CSS, how would the Joomla core be able to handle all these scenarios?

- would there be a provision for the to user be able to select which modules get converted to the AMP pages?

- what about content entered in the content manager that is not AMP compliant (i.e. let's say somebody uses JCE's Media Box), how would the conversion of complex non-compliant JavaScript be handled?

Would it just be stripped out?  How would the end-user be able to manually edit the AMP version of a page to compensate for that while maintaining AMP compliance.

- what if someone wants to publish a 'stand-alone' AMP page?

- how would such a solution optimize 'performance optimization'?

I'd say having duplicated content in your backend for AMP vs normal HTML shouldn't happen.

I agree.  I guess what bothers me most about the AMP Project is that I'd very much like to stick to the principles of good RWD - one design, device agnostic, and AMP seems to throw that out the window.

I general, I see your proposed solution as close to what I, as web designer, would ideally like...BUT

Just looking at Bootstrap alone compared to AMP,  I am not sure how the two can co-exist.

Look at all the available components in Bootstrap (let's call this the regular HTML) - ALL those would have to be able to have equivalents in AMP for modules which rely on those in order for them to be translated.

This, in my (albeit limited) view seems to be a task that is so complex, with no viable workaround - I just don't see how it is going to be achieved.

I think that content needs to be entered in a different way to begin with (including a content editor that restricts the user to using only AMP compliant styles and components).

We have to begin by asking the following questions when it comes AMP pages

1) Do we restrict the current freedom of users to enter content into the CMS that can readily be converted to AMP?

2) If not, what happens to the content?

So, I've come to the conclusion that although undesirable, in the end, there is no realistic workaround to duplicate content - on version in AMP and one version in 'regular HTML.'

I see that you've reached a different conclusion - I trust your judgement and expertise on this far more than my own - I just wanted to take a moment to share some of these thoughts with you.

Best,

N

  

[Michael Babker]

You're still thinking about this as the final product which is a full page composition.  Break it down further into the various steps that Joomla goes through to process data and I think you'll start to understand the approach I'm looking at.

In a normal request cycle, once Joomla has been booted up and has routed the request, the next thing that happens is the component that has been requested is dispatched.  During this process, only the individual component's data is processed and anything from associated plugin events during that dispatch cycle.  After the component is dispatched, the full page's output is compiled together via the JDocument API.  For HTML requests, it's during this step that Joomla first parses the template's index.php file and figures out what extra data is needed to assemble the page, marked by the <jdoc> tags.  While in the scope of the component, Joomla itself is still blissfully unaware of what the final page composition is going to look like other than the response format (designated by either a menu item's configuration or the request URI which can specify this).  JDocument is instantiated during the dispatch process just before the component is first executed, so components (and the underlying MVC API) have some awareness of this response format based in part on the JDocument object which has been built.

My suggestion of a new JDocument handler is consistent with the existing behaviors of Joomla and affects workflow minimally.  Instead of using the JDocumentHTML object to render the page, which is when modules are processed, I would use a new JDocumentAmp handler to assemble the page contents.  So in the case of a category list in com_content, there are already view format classes for feed and HTML formats (https://github.com/joomla/joomla-cms/tree/staging/components/com_content/views/category).  Here we add an additional view format class in a view.amp.php file which is responsible for querying the needed data, triggering relevant plugin events, and rendering the relevant layout(s).  For all intents and purposes, this view.amp.php file could do most everything the view.html.php file does.  So this is how you'd get the category view of com_content compatible with AMP in my workflow; absolutely nothing at all changes in the scope of content management at the component level.  The same logic of these view format classes applies universally to any component built using Joomla's MVC layer; consult the documentation of extensions which have rolled their own framework layer to see how they handle similar logic.

The question of converting some HTML elements to AMP can be demonstrated at a code level using the WordPress plugin.  Specifically, their AMP_Content::transform() (https://github.com/Automattic/amp-wp/blob/6dc5eb07eb5aceaa8bc76388becf17e709d0e14b/class-amp-content.php#L22) method is called which handles conversion of simple elements.  What's interesting for us for this discussion is the AMP_Sanitizer class (https://github.com/Automattic/amp-wp/blob/master/class-amp-sanitizer.php) and the element converters (for example AMP_Img_Converter at https://github.com/Automattic/amp-wp/blob/master/class-amp-img.php).  These show some of the logic they use to post process a post item to remove blacklisted elements and convert elements with AMP comparable syntaxes.

Tying everything back together into Joomla architecture now.  Without typing out a full book on Joomla architecture, you're going to have to follow JDocumentHTML::render() (https://github.com/joomla/joomla-cms/blob/3.5.0-beta/libraries/joomla/document/html/html.php#L468) to see how the full HTML page comes together.  But basically it involves reading that template's index.php file, parsing the file's contents for <jdoc> tags, rendering them via one of the available renderers for the HTML format (https://github.com/joomla/joomla-cms/tree/3.5.0-beta/libraries/joomla/document/html/renderer), and assembling it into a valid HTML document.  Essentially, the same would be done for AMP format pages.  Instead of module renderers though (for the first pass), these renderer objects would probably look similar to the WordPress plugin's classes in terms of function (especially when taking the component output and manipulating things).  A similar renderer for the <head> element would need to be created also to handle assembling that in compliance with the AMP spec.  Borrowing some logic out of the error document handler (https://github.com/joomla/joomla-cms/blob/3.5.0-beta/libraries/joomla/document/error/error.php#L97), we'd have a default system template for AMP pages and allow templates to create a custom template which allows folks to theme the AMP page (within the limitations of the spec, there's nothing that says it has to be pure unstyled HTML).  Modules for this first pass wouldn't be rendered at all, so their output and how they'd affect the global JDocument object doesn't come into play for the first iteration of things; the other non-HTML view formats don't natively render modules either.

Plugins are certainly going to be tricky to deal with for a lot of reasons.  Picking on the loadmodule plugin for a minute since it allows modules to be dynamically rendered into an item's contents.  Do we want these modules to be rendered into AMP pages?  At first, probably not.  On the Developer Network we're using this to render charts which aren't AMP compliant because of the use of JavaScript, so in lieu of a flag somewhere to tell the module to behave differently for AMP, we just don't render it.  That still leaves the issue of removing the {loadmodule} placeholder.  Another potentially problematic plugin could be the vote plugin.  I'm not fully aware of what AMP suggests to do with form elements, so is it possible to submit votes via a form submission on the AMP page?  Is it still feasible to render the vote data on the AMP page and exclude the form?  Just two examples of plugins in core that need to be looked at and adjusted.

So getting back to things from the user perspective after the rather technical side-rant.  In Joomla you don't have a way to edit how an article is rendered for the different view formats.  Whether it be an RSS or Atom feed or an HTML page, the same article that you've created via the Article Manager is processed (the HTML that you've entered in the editor space and all associated metadata).  There's no need to create separate articles (in the context of com_content articles, not full page composition) for the AMP format pages.  If the views of the components you're using support AMP, then at most the end user would need to be able to theme the output on the AMP page.  If the component's views don't support AMP, then there's nothing for Joomla to do other than handle the error condition that would arise (which is already covered by the existing error handlers).  If, and only if, AMP expands to include secondary content types, then the discussion shifts toward how a user assigns modules or menu items to an AMP page (as an example).

Summing up the whole duplicate content thing.  Yes, via URIs, your site will have duplicate content.  This is a side effect of how AMP is structured and something they basically dictate, it is not a software platform limitation (at the CMS level).  No, your site's admin does not require duplicated content (you don't need modules for normal HTML pages versus AMP pages; right now there are no modules in AMP; likewise for com_content the same articles you create would be processed for HTML or AMP pages).  The user does not need to maintain multiple copies of various component contents, unless they absolutely require this level of advanced logic which would be a technical detail to be implemented after the initial rollout.

[brian teeman]

If I read it correctly Michael AMP is content only. No interaction and no forms

[Niv Froehlich]

First of all, Michael, thank you so much for such a detailed response.

Of course, I trust your judgement far better than my own on this.

The user does not need to maintain multiple copies of various component contents, unless they absolutely require this level of advanced logic which would be a technical detail to be implemented after the initial rollout.

I'm wondering is another approach might be warranted - somehow marrying the two ideas.

1) Automating AMP output;

2) Provide the user with ability to edit the AMP version of the article.


Whether 2) above is done via a specific 'Article Type' or some other method may be the subject for debate.

We also have to keep in mind that "the end goal for having an AMP version of the page is much more than just having an AMP version of the page."

As a publisher wanting to rank high on SERPs (or just create a blazingly fast mobile experience), I'd want to cut out all 'non-essential' items, or anything that negatively impacts speed - that's the whole point of what we are doing - otherwise, what would be the point of creating AMP pages to begin with?

So rather than just 'automate' it all, and end there (I very much love the idea of having and option to automate AMP pages, BTW) - I'd like think about how we can also provide the user with a sufficient level of control to effectively over-ride the automated output - so that publishers can then optimize AMP pages for performance.

So in the end, I'm wondering if we can find a way to both 'automate' and 'customize' AMP pages - this is actually the greatest feature about Joomla - the ability to configure globally all the way down to specific instances.

This may be as simple as providing options in the existing articles, for example

Use same content for AMP pages (Y/N)

If no, provide a content editor for the AMP page.

I think that module assignment, etc. might be able to follow the same pattern.

Also, with regard to what Brian mentions (AMP not intended for forms) - and what you've mentioned before (AMP suitable for content pages), we have to be careful that any automated AMP pages apply to only the intended/appropriate type of pages.

Just a side note - As I publisher, I would think very hard about including a poll on an AMP page (seems to defeat the purpose).   Instead, I would put a link to the poll - keeping the AMP light as possible.

We don't want to 'recreate everything' from regular HTML pages just because we can and we can make it fit the standard, we want to keep AMP pages fast...but perhaps this is an entirely different discussion.

I don't think I can add any more value to this discussion - so at this point, I would like to thank you and leave the discussion to the real pros!

I am very excited about the adoption of AMP in Joomla!

Please feel free to let me know how I can be of assistance.

Cheers,

N





 

On Sat, Nov 21, 2015 at 7:08 PM, brian teeman <joom...@googlemail.com> wrote:

If I read it correctly Michael AMP is content only. No interaction and no forms

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[kisswebdesign]

Thanks Michael, great post.

On Saturday, 21 November 2015 23:55:37 UTC, Michael Babker wrote:

You're still thinking about this as the final product which is a full page composition.  Break it down further into the various steps that Joomla goes through to process data and I think you'll start to understand the approach I'm looking at.

OK. I think I'm getting it now.

Just the content, no interaction, no forms. Served in a special view that cuts out everything but the content - like using the "Reader" view in Firefox (with a little more CSS).

As a prolific consumer of material online, and 80%+ of that consumed via mobile (I use desktop/laptop for work, for creating, and mobile for consuming), I hate being served something different from the normal website when I view it on my phone.

So, and maybe this is for google too, will there be a way for a visitor to opt-out of AMP content for a site?

I mean, will there be a cookie (or other method) that the Joomla site can set (on request) to say "I don't want any AMP pages, show me the canonical ones only"?
Or the other way round "Show me AMP pages when available" - although that would kind of break the whole point of having them available and served on the first visit (speed and size) so is probably a stupid idea (but I'll leave it here to show my thought process).
Or is that for a browser add-on or setting to do?

I may be strange (an edge case) for not wanting different experiences of websites/content/pages on mobile, tablet, small laptop, big laptop and desktop, but I do think it should be a choice.
As a consumer I would be (am) more likely to bounce from a site that serves me a special page because of the device I'm using to view it than I am otherwise, not sure how many others do that but surely site owners want people to stay on their site (and choice increases the probability I will stay).
Aside: I send emails/contact form messages to sites that do the 'different content' thing moaning about it. I can be (am) a right pain in the arse.

Also, probably one for Google, who decides when to serve an AMP page, and how is the decision made?
I may be happy to get an AMP page if I am on a non-all-you-can-eat 3G (or GSM/2G) data plan, but the same device on wifi I want the full experience.
Is it screen size (or viewport size) + browser id, how about orientation, or is there some smart network type or speed assessment (or should there be).

There are follow-up questions to that, but I'll try to get back to Joomla implementations/implications.

nope, nothing more at this time ;-)

[Niv Froehlich]

Just FYI - some of the questions we are having on AMP (more and more everyday) relating to AMP HTML are surfacing on http://stackoverflow.com/search?q=amp-html

[Robert G Mears]

Inasmuch as this may be ... ah ... out in left field ... Peter at NoNumber provides the option in his extension Modules Anywhere to choose whether a module displays based on browser. Perhaps this can be incorporated into how Joomla content displays vis a vis AMP.

[Seth Warburton]

Things I'm not currently understanding in any of the AMP threads:

1. Why AMP is seen as the only option to making crazy-fast, mobile friendly websites with Joomla.
2. Why menus are seen as any sort of problem at all?
3. Why we'd be jumping into a half-baked spec whose primary purpose is to help Google make more ad revenue.

As it currently stands it is easier to make fast, mobile-friendly, accessible, content-focussed websites with what we currently have than it is with AMP, why are we not putting this much focus into achieving that? 

I think we should first be concentrating on If that doesn't happen we'll making fast, accessible, user-friendly sites with the tried-and-tested technologies we already have, before we all start chasing magical unicorns around. 

Let's start thinking about making good html pages first eh? When we've done that we can ask what benefit an AMP version would bring.

[Seth Warburton]

Sorry, the third paragraph should read:

I think we should first be concentrating on making fast, accessible, user-friendly sites with the tried-and-tested technologies we already have, before we all start chasing magical unicorns around. 

[MonkeyT]

Given that AMP is a matter of strict compatibility with a standard, rather than enforcing that standard in the editor, would it be a better idea to simply add a compatibility testing API for each of the content modules to use when that content is saved?  

If I view a list of templates, I could appreciate an indicator which says "This template contradicts the AMP standard"  meaning it calls unapproved javascript or restricted header elements.

In a list of articles, to see an indicator which says "This content doesn't contradict the AMP standard"  meaning only approved HTML tags were found within it.

Perhaps even categories could examine their contents for "success" flags, to determine whether "All content within this category meets the AMP standard." If any of the content fails to have that "success" flag, any menu item which gathers multiple content items from that category would not be considered AMP compatible.  

If we could verify AMP compatible content as it was entered and allow groups or categories to examine the status of their content,  it seems possible that we could build a tool under the Menu manager to display which published links might not be AMP compatible based on what pieces they could display.

I'm not certain we could test modules or plugins which generate dynamic content, but they could be scanned for header includes, javascript embedding and such.

It might be a viable alternate strategy, rather than a second set of file formats or editing tools.  

[Niv Froehlich]

@ Seth

Things I'm not currently understanding in any of the AMP threads:

 

Why AMP is seen as the only option to making crazy-fast, mobile friendly websites with Joomla.

It's not.  AMP is not necessary if the only objective is to make mobile pages super-fast.  In fact, in most cases, proper optimization of images would make a much bigger impact than using the AMP standard.  However, AMP does have some provisions in it to speed up page rendering, including working in concert with Google's CDNs, caching mechanisms, loading/unloading assets on an 'as needed' basis (doesn't load any assets which are rendered below the page fold).

Why menus are seen as any sort of problem at all?

Currently, there is no specification or guidance in the AMP standard for menus at all.  This may come, but the question, how to handle this in the interim and inline with optimizing performance. 

Why we'd be jumping into a half-baked spec whose primary purpose is to help Google make more ad revenue.

 
I, as well as many leading authorities in this space, personally agree with both your premises that the spec is a "half-baked," and it's primary purpose is to help Google make more ad revenue.

I wouldn't have much interest in AMP (it's not that difficult to make RWD pages that load and render quickly), but Google (although they claim these are matters 'under active discussion') will advantage AMP pages in their mobile SERPs.  

Therefore, if search rankings are important, on is at a competitive advantage with AMP, and conversely, at competitive 'disadvantage' without AMP.

Google has publicly stated that they are already advantaging speed on SERPs (although a 2013 study by MOZ disproved this), speed will be an ever increasing factor in SERP rankings.

I probably sound very much like a broken record by now, but there will be 2 factors to success (in the following priority)

1) Make your mobile pages 'blazingly fast'; and

2) Maker 'blazingly fast' mobile pages AMP compliant.

---

@MonkeyT

In general, dynamic content should not be served up in AMP pages.

Malte Ubl, the AMP Project tech lead:
The web today is many things: an application platform, an e-commerce platform, a content platform, a gaming platform, and so much more. We decided to focus entirely on static content as it lends itself to more radical optimization approaches that are easier to apply across the board.

Quoted from Get AMP’d: Here’s what publishers need to know about Google’s new plan to speed up your website

--

Cheers,

N

 

--

[Seth Warburton]

The priority should be to make our pages blazing fast and accessible, as both of these things will 1) always be desirable to users 2) always be beneficial to site owners.

Google has a long and glorious history of introducing 'advantages' which, when they fail to increase their ad revenue, are then discontinued. Google Authorship program anyone?

An Open Web is also important, at least it is to me and I assume that the idealology of an Open Source project would also extend to an Open Web. An Open Web does not have a central authority that writes and approves  it's own spec, strictly regulating development (to it's own advantage). A proper open solution would be built upon the top if the existing framework we have for building the web, html. User-empowering, speed-boosting features like no-js, no images without sizes, below-fold rendering on demand, etc. can better be implemented within a browser in a standards-compliant way. Safari's Reader View is a nice example of how that could happen without building a parallel, proprietary 'web'.

Menus? Perhaps there's no guidance on menus because there doesn't need to be. List elements are still allowed AFAIK.

Cheers,

Seth

[Niv Froehlich]

Google has a long and glorious history of introducing 'advantages' which, when they fail to increase their ad revenue, are then discontinued.

Believe me, I'd love to see AMP in the 'discontinued' bin.

An Open Web is also important, at least it is to me and I assume that the ideology of an Open Source project would also extend to an Open Web.

Agreed.  This is perhaps the biggest of all the criticisms against the Google AMP project.

If it means anything to anyone, I cursed in tongues that would make a sailor blush, at least several, times while reviewing the new 'standard.'

Cheers,

N

[Robert G Mears]

There's the rub:
 

[AMP]'s primary purpose is to help Google make more ad revenue.

There are people hosting websites who don't want to do that. Some of them build their websites with Joomla!.

[Niv Froehlich]

There are people hosting websites who don't want to do that. Some of them build their websites with Joomla!.

This can be handled through an 'option' in the admin, nobody forced to use it.

N 

--

[George Wilson]

It's not making google ad revenue by displaying adverts. It's making google get more ad revenue by making the internet better for mobile users. If people use an app instead of the internet then by default won't be showing adverts and thus make less money. I think improving the quality of websites is a goal we can all aspire to whatever the ultimate motivation.

Kind Regards,

George

[Niv Froehlich]

 I think improving the quality of websites is a goal we can all aspire to whatever the ultimate motivation.

The main gripe, from what I see, inter alia, is that this is more the domain the W3C (and hence could have been a standard developed and promoted through the W3C).

Google, as sole-arbiter of gets included in the standard, is already advantaging it's own technologies.

Conversely, some people do believe such a standard would never get adopted if the Search Engines (esp. Google) didn't enforce speed via advantaging SERP results.

As it stands, many believe that the mobile web is 'broken' - not because standards don't exist to make the mobile web faster and more friendly, but because people are not adopting best-practices, for example

1) pages are not being optimized for performance, and content consumers usually are subject to abnormally long page loads (ancillary to this is high rates of abandonment on click-throughs from SERPs)

2) Mobile pages, which include ads from various networks, become impossible to read.  You begin reading, a page jumps as an ad finally loads, you scroll like mad to relocate the content you where reading, and the cycle continues.

3) Ad networks have gotten used to using 'sloppy' wrought with high latency issues

It's not making google ad revenue by displaying adverts

To be clear, Google does earn huge revenues through AdSense (which is voluntary for any publisher - one can have no ads or use ad networks of choice).

Their fear is that mobile web users will resort to 'ad blocking,' because #2 and #3 above have become intolerable, and if that happens - bye-bye ad revenue.   Obviously Google wants to protect their income sources. 

Find ways to fix anyone of these and we all benefit - that's true, and that's the "proposition" upon which Google justifies the AMP Project to the community.

From the perspective of us as 'Joomlers,' my view is that many publishers would want to take advantage of AMP capabilities - so in-spite of all the arguments, the Joomla! Project needs to keep the CMS relevant and an attractive option.  It makes sense, therefore, to adopt AMP.

With in mind, folks such as myself really rely on the PLT to evaluate priorities and best approaches for implementation (thank you PLT!!!)

Cheers,

N

--

[Hannes Papenberg]

Google has more than once pushed a technology that was later then
adopted by the W3C. Large parts of CSS3 wouldn't exist if Google hadn't
agressively pushed it into Chrome and hadn't started (a long time ago)
to favour properly coded websites over split photoshop images. Likewise
with accessibillity features and quite a chunk of mobile-first
technologies. I'm definitely not a fan of Google and I think that their
mountains of data are at least spooky, but I wouldn't know a case where
Google has tried to harm the web with their push for new technology.

Of course they have an interest in showing their advertisements. It is
their main income. But Google also is the company that promoted reduced
ads that removed most of the visual garbage from websites. They also
provide graphical ads, yes, but the problem is not the lone graphical ad
here or there. It is the marketing departments that put more ads on a
website then actual content. You brought the arguments already.

Your result from all of this is that we HAVE to adopt AMP. I'm saying
that we will not gain anything by that as long as marketing will again
go ahead and force a bazillion ads on the page. AMP is the attempt to
solve a social problem with a technical solution. And that very rarely
works.

Hannes

Am 25.11.2015 um 14:33 schrieb Niv Froehlich:
>
> I think improving the quality of websites is a goal we can all
> aspire to whatever the ultimate motivation.
>
>

> The main gripe, from what I see, /inter alia, /is that this is more

> the domain the W3C (and hence could have been a standard developed and
> promoted through the W3C).
>

> /Google, as sole-arbiter of gets included in the standard, is already
> advantaging it's own technologies./
>
> Conversely, some people do believe _such a standard would never get

> adopted if the Search Engines (esp. Google) didn't enforce speed via

> advantaging SERP results_.
>
> As it stands, /many believe that the mobile web is 'broken'/ - not

> because standards don't exist to make the mobile web faster and more

> friendly, but because /people are not adopting best-practices/, for

> example
>
> 1) pages are not being optimized for performance, and content
> consumers usually are subject to abnormally long page loads (ancillary
> to this is high rates of abandonment on click-throughs from SERPs)
>
> 2) Mobile pages, which include ads from various networks, become
> impossible to read. You begin reading, a page jumps as an ad finally
> loads, you scroll like mad to relocate the content you where reading,
> and the cycle continues.
>
> 3) Ad networks have gotten used to using 'sloppy' wrought with high
> latency issues
>
> It's not making google ad revenue by displaying adverts
>
>
> To be clear, Google does earn huge revenues through AdSense (which is

> /voluntary/ for any publisher - one can have no ads or use ad networks

> of choice).
>
> Their fear is that mobile web users will resort to 'ad blocking,'
> because #2 and #3 above have become intolerable, and if that happens -
> bye-bye ad revenue. Obviously Google wants to protect their income
> sources.
>

> /Find ways to fix anyone of these and _we all benefit_ - that's true,

> and that's the "proposition" upon which Google justifies the AMP

> Project to the community./

>
> From the perspective of us as 'Joomlers,' my view is that many
> publishers would want to take advantage of AMP capabilities - so

> in-spite of all the arguments, the */Joomla! Project needs to keep the

> CMS relevant and an attractive option. It makes sense, therefore, to

> adopt AMP./*

>
> With in mind, folks such as myself really rely on the PLT to evaluate
> priorities and best approaches for implementation (thank you PLT!!!)
>
> Cheers,
>
> N
>
>
>
> On Wed, Nov 25, 2015 at 7:38 AM, George Wilson
> <georgeja...@googlemail.com

> <mailto:georgeja...@googlemail.com>> wrote:
>
> It's not making google ad revenue by displaying adverts. It's
> making google get more ad revenue by making the internet better
> for mobile users. If people use an app instead of the internet
> then by default won't be showing adverts and thus make less money.
> I think improving the quality of websites is a goal we can all
> aspire to whatever the ultimate motivation.
>
> Kind Regards,
> George
>
>
> On Wednesday, November 25, 2015 at 9:23:42 AM UTC, Robert G Mears
> wrote:
>
> There's the rub:
>
> [AMP]'s primary purpose is to help Google make more ad
> revenue.
>
>
> There are people hosting websites who don't want to do that.
> Some of them build their websites with Joomla!.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Michael Babker]

The same financial ulterior motives can be said about any organization, product, or mission.  If you're really naive enough to think that everyone just does stuff to make the world a better place, as nice as the feeling might be, I can only say "get real".  So here's the way I see it, you don't want Google's profits to grow because your site's content can be displayed in a context that makes them money.  Here's one way to slow that down, place this snippet in your site's robots.txt file:

User-agent: Googlebot

Disallow: /

Here's my two cents.  Google is a commercial entity providing numerous services, some of which include email platforms, website hosting, and search indexing.  Most of those are generally free to end users but also include premium tiers/features.  Google has released a new proposal for a way to alter HTML documents in a manner which takes advantage of their platform's services.  Again, this is free to the end user on the condition that they meet the terms and conditions.  Considering that Google (and its parent Alphabet) are for profit entities, if they want to alter their services in a way that gives an end user an advantage in other places for using their company's services, it's within their rights so long as it stays within the constraints of the law.

As for the debate about whether Joomla should adopt or not, at this point I'm seriously leaning toward saying screw it and sitting back with a bucket of popcorn and a cooler of preferred choice beverages and watching Joomla become more irrelevant than it already is.  Every other major platform in PHP is continuing to evolve in some form, every other major community in PHP somehow collaborates among one another, and Joomla's sitting in the corner by itself because its not part of the cool kids club anymore.  No, adopting AMP doesn't magically fix that; hell it doesn't even make Joomla a leader (Automattic already has a functioning system for WordPress and Drupal has a similar project started).

[Niv Froehlich]

IMHO - 2 separate discussions are being had.

1) Should we adopt AMP?

2) What's the best implementation?

I agree with Michael in that Joomla will become irrelevant if aren't focused on adopting the 'new' techs.

Also, if we spend too much time focusing on 1) and not 2), is the best use of our time and resources?

I think as long as the feature is optional (i.e. can be toggled on/off), then arguments on 1 (esp. philosophical points) are moot, and because of that, I think that we are wasting a lot of time and energy on 'philosophical' discussions.

Is adoption of AMP still even a question at this point?

Is it safe to say that the PLT has decided to adopt AMP, now let's move on to 'implementation'?

Just my opinion.

N