FYI. Google just announced an open source project to create a speedier framework for mobile browsing. It might be worth looking at what they're doing:
From: http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-th...
Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages https://www.ampproject.org/ — which aims to speed up the delivery of web content to mobile devices https://www.ampproject.org/how-it-works/. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub https://github.com/ampproject/amphtml and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ https://www.ampproject.org/faq/ has a few more details.
Google blog announcement: https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages...
Cool.
Pine On Oct 8, 2015 8:05 AM, "Jon Katz" jkatz@wikimedia.org wrote:
FYI. Google just announced an open source project to create a speedier framework for mobile browsing. It might be worth looking at what they're doing:
From:
http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-th...
Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages https://www.ampproject.org/ — which aims to speed up the delivery of web content to mobile devices https://www.ampproject.org/how-it-works/. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub https://github.com/ampproject/amphtml and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ https://www.ampproject.org/faq/ has a few more details.
Google blog announcement:
https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Best big-picture article I saw on it last night was http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know...
On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz jkatz@wikimedia.org wrote:
FYI. Google just announced an open source project to create a speedier framework for mobile browsing. It might be worth looking at what they're doing:
From:
http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-th...
Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages https://www.ampproject.org/ — which aims to speed up the delivery of web content to mobile devices https://www.ampproject.org/how-it-works/. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub https://github.com/ampproject/amphtml and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ https://www.ampproject.org/faq/ has a few more details.
Google blog announcement:
https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Yes, the Niemanlab summary is really informative. Read it last night and this part kind of jumped out at me:
*"There are lots of clever ideas here, and it’s understandable why these constraints would help improve performance. For better and for worse, this is essentially a rollback of how HTML and web technologies have evolved over the past decade. It’s a little jarring that so many of the sample AMP pages on display this morning look a lot like the web of, say, 2002, shrunk down to a phone screen.: "*
Reminds one of a certain website that's often accused (quite rightfully) of being stuck in 2002... Another point of the article is that a lot of the perf improvements are being achieved by ruthlessly banning third party ads and trackers, both of which Wikipedia does anyway because of our neutrality and privacy principles.
On Thu, Oct 8, 2015 at 9:53 AM, Luis Villa lvilla@wikimedia.org wrote:
Best big-picture article I saw on it last night was http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know...
On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz jkatz@wikimedia.org wrote:
FYI. Google just announced an open source project to create a speedier framework for mobile browsing. It might be worth looking at what they're doing:
From:
http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-th...
Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages https://www.ampproject.org/ — which aims to speed up the delivery of web content to mobile devices https://www.ampproject.org/how-it-works/. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub https://github.com/ampproject/amphtml and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ https://www.ampproject.org/faq/ has a few more details.
Google blog announcement:
https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
I had instant flashbacks to WAP 2.0 when I read about AMP.. Let’s make a variant of normal websites, that solves problems for mobile, by limiting options on authors and readers alike..
Past experience shows that this just doesn’t work. At least not for those parties that are already no able to deliver a proper secondary channel.
DJ
On 8 okt. 2015, at 19:23, Tilman Bayer tbayer@wikimedia.org wrote:
Yes, the Niemanlab summary is really informative. Read it last night and this part kind of jumped out at me:
"There are lots of clever ideas here, and it’s understandable why these constraints would help improve performance. For better and for worse, this is essentially a rollback of how HTML and web technologies have evolved over the past decade. It’s a little jarring that so many of the sample AMP pages on display this morning look a lot like the web of, say, 2002, shrunk down to a phone screen.: "
Reminds one of a certain website that's often accused (quite rightfully) of being stuck in 2002... Another point of the article is that a lot of the perf improvements are being achieved by ruthlessly banning third party ads and trackers, both of which Wikipedia does anyway because of our neutrality and privacy principles.
On Thu, Oct 8, 2015 at 9:53 AM, Luis Villa <lvilla@wikimedia.org mailto:lvilla@wikimedia.org> wrote: Best big-picture article I saw on it last night was http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know... http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know-about-googles-new-plan-to-speed-up-your-website/
On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz <jkatz@wikimedia.org mailto:jkatz@wikimedia.org> wrote: FYI. Google just announced an open source project to create a speedier framework for mobile browsing. It might be worth looking at what they're doing:
From: http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-th... http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-the-mobile-web?utm_source=rss1.0mainlinkanon&utm_medium=feed
Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages https://www.ampproject.org/ — which aims to speed up the delivery of web content to mobile devices https://www.ampproject.org/how-it-works/. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub https://github.com/ampproject/amphtml and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ https://www.ampproject.org/faq/ has a few more details.
Google blog announcement: https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages... https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org mailto:Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation Working towards a world in which every single human being can freely share in the sum of all knowledge.
reading-wmf mailing list reading-wmf@lists.wikimedia.org mailto:reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf https://lists.wikimedia.org/mailman/listinfo/reading-wmf
-- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org mailto:Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l https://lists.wikimedia.org/mailman/listinfo/mobile-l
We currently have at least 6 channels, I believe:
1. Desktop Web 2. Mobile Web 3. Android phone 4. Android tablet 5. IPhone 6. Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could experiment with Google's idea on just one channel to start?
Pine On Oct 8, 2015 12:23 PM, "Derk-Jan Hartman" d.j.hartman+wmf_ml@gmail.com wrote:
I had instant flashbacks to WAP 2.0 when I read about AMP.. Let’s make a variant of normal websites, that solves problems for mobile, by limiting options on authors and readers alike..
Past experience shows that this just doesn’t work. At least not for those parties that are already no able to deliver a proper secondary channel.
DJ
On 8 okt. 2015, at 19:23, Tilman Bayer tbayer@wikimedia.org wrote:
Yes, the Niemanlab summary is really informative. Read it last night and this part kind of jumped out at me:
*"There are lots of clever ideas here, and it’s understandable why these constraints would help improve performance. For better and for worse, this is essentially a rollback of how HTML and web technologies have evolved over the past decade. It’s a little jarring that so many of the sample AMP pages on display this morning look a lot like the web of, say, 2002, shrunk down to a phone screen.: "*
Reminds one of a certain website that's often accused (quite rightfully) of being stuck in 2002... Another point of the article is that a lot of the perf improvements are being achieved by ruthlessly banning third party ads and trackers, both of which Wikipedia does anyway because of our neutrality and privacy principles.
On Thu, Oct 8, 2015 at 9:53 AM, Luis Villa lvilla@wikimedia.org wrote:
Best big-picture article I saw on it last night was http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know...
On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz jkatz@wikimedia.org wrote:
FYI. Google just announced an open source project to create a speedier framework for mobile browsing. It might be worth looking at what they're doing:
From:
http://tech.slashdot.org/story/15/10/08/035200/googles-effort-to-speed-up-th...
Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages https://www.ampproject.org/ — which aims to speed up the delivery of web content to mobile devices https://www.ampproject.org/how-it-works/. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub https://github.com/ampproject/amphtml and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ https://www.ampproject.org/faq/ has a few more details.
Google blog announcement:
https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages...
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
reading-wmf mailing list reading-wmf@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf
-- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could experiment with Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could experiment
with
Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" <bd808@wikimedia.org javascript:_e(%7B%7D,'cvml','bd808@wikimedia.org');> wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W <wiki.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@gmail.com');> wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could experiment
with
Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation <bd808@wikimedia.org javascript:_e(%7B%7D,'cvml','bd808@wikimedia.org');> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two + slim opportunity for growth is way better than the guaranteed never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could experiment
with
Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere and also might be troublesome for those who prefer google not to track their reading.
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
-Toby
[1] https://phabricator.wikimedia.org/T114542
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two + slim opportunity for growth is way better than the guaranteed never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could experiment
with
Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
I've been checking this out and I have a few thoughts I'd like to share (basically, what Bryan said):
- This feels like google's attempt to be again the hub for a big part of the web, to gather more information and data for it's ad business. True, anybody could spin up a amp cache system, but they will have the fastest/best/biggest one. - This is just using a subset of HTML, and severely limiting any interactivity, only whitelisted pixel tracking and amp approved ad services allowed. It is even worse that the 2002 web. If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN). - Check the FAQ out, ample support for user tracking, ad serving and paywalls. Supporting this is supporting another closed for-profit web with Google at the front of all users.
On the surface, AMP *seems* extremely heavy handed. It’s restricting for
developers and puts publishers in a squeeze over the technology they can use — right now, many are heavily leveraging Javascript for tracking and other experiences on their sites. On the other hand, AMP offers far more flexibility than both Apple and Facebook do, is hugely beneficial for users and faster load times should lead to keeping even more of them. AMP might finally push the Web in a much more positive direction — one that’s faster, with less cumbersome JavaScript everywhere.
*http://thenextweb.com/insider/2015/10/07/googles-plan-to-speed-up-the-mobile... http://thenextweb.com/insider/2015/10/07/googles-plan-to-speed-up-the-mobile-web-burn-it-down/*
I really don't see how this could be a good idea for us in it's current form.
That said, it would be great to keep in mind the ideas and apply them to our platform to guide us on how to serve our users better.
On Fri, Oct 9, 2015 at 2:39 AM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere and also might be troublesome for those who prefer google not to track their reading.
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
-Toby
[1] https://phabricator.wikimedia.org/T114542
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two + slim opportunity for growth is way better than the guaranteed never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could
experiment with
Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Can we start a proposal to make all mobile websites look like 8-bit video games? That should be pretty performant ;-)
Humor aside, just want to +1 this discussion, has been very insightful for me both in terms of making me aware of this proposal by Google and breaking it down pretty thoroughly. Thanks for sharing everyone!
On Fri, Oct 9, 2015 at 3:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I've been checking this out and I have a few thoughts I'd like to share (basically, what Bryan said):
- This feels like google's attempt to be again the hub for a big part
of the web, to gather more information and data for it's ad business. True, anybody could spin up a amp cache system, but they will have the fastest/best/biggest one.
- This is just using a subset of HTML, and severely limiting any
interactivity, only whitelisted pixel tracking and amp approved ad services allowed. It is even worse that the 2002 web. If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN).
- Check the FAQ out, ample support for user tracking, ad serving and
paywalls. Supporting this is supporting another closed for-profit web with Google at the front of all users.
On the surface, AMP *seems* extremely heavy handed. It’s restricting for
developers and puts publishers in a squeeze over the technology they can use — right now, many are heavily leveraging Javascript for tracking and other experiences on their sites. On the other hand, AMP offers far more flexibility than both Apple and Facebook do, is hugely beneficial for users and faster load times should lead to keeping even more of them. AMP might finally push the Web in a much more positive direction — one that’s faster, with less cumbersome JavaScript everywhere.
*http://thenextweb.com/insider/2015/10/07/googles-plan-to-speed-up-the-mobile... http://thenextweb.com/insider/2015/10/07/googles-plan-to-speed-up-the-mobile-web-burn-it-down/*
I really don't see how this could be a good idea for us in it's current form.
That said, it would be great to keep in mind the ideas and apply them to our platform to guide us on how to serve our users better.
On Fri, Oct 9, 2015 at 2:39 AM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere and also might be troublesome for those who prefer google not to track their reading.
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
-Toby
[1] https://phabricator.wikimedia.org/T114542
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two
- slim opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote: > We currently have at least 6 channels, I believe: > > 1. Desktop Web > 2. Mobile Web > 3. Android phone > 4. Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
> 5. IPhone > 6. Legacy Android phone > > I'm no expert on mobile developmemt, but perhaps WMF could experiment with > Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation <bd808@wikimedia.org > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
I agree that the companies all have (essentially[1]) the same motives at the company level. The difference is that Google's technical approach to solving the latency problem is not explicitly tied to Google or to particular Google apps. (There is a pure web demo, for example, which works in any mobile browser, including Firefox for Android, and Twitter - a Google competitor - has already adopted it.) In contrast, Facebook and Apple's "solutions" for fast reading are very explicitly tied to (1) apps, not browsers, and (2) apps specifically from those companies. There will never be a future where Facebook's solution for latency works outside of Facebook; there is (at least in theory, and possibly in practice w/ Twitter) such a future with AMP.
Or to put it another way: Google's solution still might not be good, but it's at least possible that it could keep content on the open web; Facebook and Apple are pretty explicitly trying to kill the open web. There is no way the long game of the FB/Apple apps lead to good outcomes for independent publishers like us.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere
Oh, definitely won't. But it might give us some leverage in those discussions - having conceded that the analytics from some cached pages should be shared, it is no longer such a huge leap to analytics on other types of "cached"/processed data.
and also might be troublesome for those who prefer google not to track their reading.
There is a lot of devil in those details, of course, but for those coming from Google Search (still the vast majority of our users) the first leap is already tracked/known to Google. This doesn't necessarily make that worse. (Much depends on how the caching occurs; their ability to track the *second* page you read would be new, at least for iOS users - Android users already have this problem, I believe.)
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
Great link, thanks.
[1] The subtle difference, from our perspective, is that Google has pretty strong incentives to keep the open web viable, because making sense of (and selling ads on) the open web is their core competence. Facebook and Apple, in contrast, have no strategic reason to keep the open web viable: if they can turn every publisher into a FB-only or Apple-only publisher, they'd happily do that. Of course, an open web that doesn't depend on Google would be even better, but that's not in the cards at this point unless Mozilla wakes up.
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two + slim opportunity for growth is way better than the guaranteed never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote:
We currently have at least 6 channels, I believe:
- Desktop Web
- Mobile Web
- Android phone
- Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
- IPhone
- Legacy Android phone
I'm no expert on mobile developmemt, but perhaps WMF could
experiment with
Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN).
I think this announcement + the transcoding work Google is doing show that this ^ is something we should be strongly considering. If google can transcode our content and make it significantly faster (as Gergo showed in another thread) and/or other sites are adopting similar technology, than our users are going to expect a level of speed far higher than we can currently provide. I don't care if we use google's or our own, but do want to make sure we aren't rebuilding the wheel if we don't have to.
The conversations as to whether or not google is acting out of self interest are fairly moot (they are...always), but I think Luis's points are very apt about googles self interests being more closely aligned with ours on the web than the other big players in this space.
On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa lvilla@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
I agree that the companies all have (essentially[1]) the same motives at the company level. The difference is that Google's technical approach to solving the latency problem is not explicitly tied to Google or to particular Google apps. (There is a pure web demo, for example, which works in any mobile browser, including Firefox for Android, and Twitter - a Google competitor - has already adopted it.) In contrast, Facebook and Apple's "solutions" for fast reading are very explicitly tied to (1) apps, not browsers, and (2) apps specifically from those companies. There will never be a future where Facebook's solution for latency works outside of Facebook; there is (at least in theory, and possibly in practice w/ Twitter) such a future with AMP.
Or to put it another way: Google's solution still might not be good, but it's at least possible that it could keep content on the open web; Facebook and Apple are pretty explicitly trying to kill the open web. There is no way the long game of the FB/Apple apps lead to good outcomes for independent publishers like us.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere
Oh, definitely won't. But it might give us some leverage in those discussions - having conceded that the analytics from some cached pages should be shared, it is no longer such a huge leap to analytics on other types of "cached"/processed data.
and also might be troublesome for those who prefer google not to track their reading.
There is a lot of devil in those details, of course, but for those coming from Google Search (still the vast majority of our users) the first leap is already tracked/known to Google. This doesn't necessarily make that worse. (Much depends on how the caching occurs; their ability to track the *second* page you read would be new, at least for iOS users - Android users already have this problem, I believe.)
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
Great link, thanks.
[1] The subtle difference, from our perspective, is that Google has pretty strong incentives to keep the open web viable, because making sense of (and selling ads on) the open web is their core competence. Facebook and Apple, in contrast, have no strategic reason to keep the open web viable: if they can turn every publisher into a FB-only or Apple-only publisher, they'd happily do that. Of course, an open web that doesn't depend on Google would be even better, but that's not in the cards at this point unless Mozilla wakes up.
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two
- slim opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote: > We currently have at least 6 channels, I believe: > > 1. Desktop Web > 2. Mobile Web > 3. Android phone > 4. Android tablet
I don't think that we have separate native apps for the phone and tablet form factors.
> 5. IPhone > 6. Legacy Android phone > > I'm no expert on mobile developmemt, but perhaps WMF could experiment with > Google's idea on just one channel to start?
AMP would only be appropriate for the mobile web channel from the list above. Implementing it would be a matter of placing some sort of translating proxy between MediaWiki and the requesting user agent that downgraded the HTML produced by MediaWiki to AMP's restricted HTML dialect. That sort of translation might be possible in MobileFrontend but it would likely be accomplished much more easily using some other tech stack that had good support for manipulation of HTML like a node.js service. It might be an interesting prototype project for a volunteer to experiment with a frontend app that consumed the RESTBase provided Parsoid HTML (e.g. https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out AMP compliant documents.
The only other option really to produce alternate HTML from MediaWiki would require swapping out the existing layer that translates an article's wikitext to HTML with a version that spoke AMP instead. That would be related to https://phabricator.wikimedia.org/T114194.
Bryan
Bryan Davis Wikimedia Foundation <bd808@wikimedia.org > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Google will give an introduction on AMP at SFHTML5 Meetup on 23 Oct: http://www.meetup.com/de/sfhtml5/events/219966898/
I'm in.
On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz jkatz@wikimedia.org wrote:
On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN).
I think this announcement + the transcoding work Google is doing show that this ^ is something we should be strongly considering. If google can transcode our content and make it significantly faster (as Gergo showed in another thread) and/or other sites are adopting similar technology, than our users are going to expect a level of speed far higher than we can currently provide. I don't care if we use google's or our own, but do want to make sure we aren't rebuilding the wheel if we don't have to.
The conversations as to whether or not google is acting out of self interest are fairly moot (they are...always), but I think Luis's points are very apt about googles self interests being more closely aligned with ours on the web than the other big players in this space.
On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa lvilla@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
I agree that the companies all have (essentially[1]) the same motives at the company level. The difference is that Google's technical approach to solving the latency problem is not explicitly tied to Google or to particular Google apps. (There is a pure web demo, for example, which works in any mobile browser, including Firefox for Android, and Twitter - a Google competitor - has already adopted it.) In contrast, Facebook and Apple's "solutions" for fast reading are very explicitly tied to (1) apps, not browsers, and (2) apps specifically from those companies. There will never be a future where Facebook's solution for latency works outside of Facebook; there is (at least in theory, and possibly in practice w/ Twitter) such a future with AMP.
Or to put it another way: Google's solution still might not be good, but it's at least possible that it could keep content on the open web; Facebook and Apple are pretty explicitly trying to kill the open web. There is no way the long game of the FB/Apple apps lead to good outcomes for independent publishers like us.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere
Oh, definitely won't. But it might give us some leverage in those discussions - having conceded that the analytics from some cached pages should be shared, it is no longer such a huge leap to analytics on other types of "cached"/processed data.
and also might be troublesome for those who prefer google not to track their reading.
There is a lot of devil in those details, of course, but for those coming from Google Search (still the vast majority of our users) the first leap is already tracked/known to Google. This doesn't necessarily make that worse. (Much depends on how the caching occurs; their ability to track the *second* page you read would be new, at least for iOS users - Android users already have this problem, I believe.)
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
Great link, thanks.
[1] The subtle difference, from our perspective, is that Google has pretty strong incentives to keep the open web viable, because making sense of (and selling ads on) the open web is their core competence. Facebook and Apple, in contrast, have no strategic reason to keep the open web viable: if they can turn every publisher into a FB-only or Apple-only publisher, they'd happily do that. Of course, an open web that doesn't depend on Google would be even better, but that's not in the cards at this point unless Mozilla wakes up.
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two
- slim opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
Pine On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote:
> On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote: > > We currently have at least 6 channels, I believe: > > > > 1. Desktop Web > > 2. Mobile Web > > 3. Android phone > > 4. Android tablet > > I don't think that we have separate native apps for the phone and > tablet form factors. > > > 5. IPhone > > 6. Legacy Android phone > > > > I'm no expert on mobile developmemt, but perhaps WMF could > experiment with > > Google's idea on just one channel to start? > > AMP would only be appropriate for the mobile web channel from the > list > above. Implementing it would be a matter of placing some sort of > translating proxy between MediaWiki and the requesting user agent > that > downgraded the HTML produced by MediaWiki to AMP's restricted HTML > dialect. That sort of translation might be possible in MobileFrontend > but it would likely be accomplished much more easily using some other > tech stack that had good support for manipulation of HTML like a > node.js service. It might be an interesting prototype project for a > volunteer to experiment with a frontend app that consumed the > RESTBase > provided Parsoid HTML (e.g. > https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out > AMP > compliant documents. > > The only other option really to produce alternate HTML from MediaWiki > would require swapping out the existing layer that translates an > article's wikitext to HTML with a version that spoke AMP instead. > That > would be related to https://phabricator.wikimedia.org/T114194. > > Bryan > -- > Bryan Davis Wikimedia Foundation < > bd808@wikimedia.org> > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID > USA > irc: bd808 v:415.839.6885 > x6855 >
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I'd love to go but won't be here. Let us know what you find out Volker. I'd personally be interested in what their answer is to "should wikipedia adopt this (and why)" On 12 Oct 2015 12:51 pm, "Volker Eckl" veckl@wikimedia.org wrote:
Google will give an introduction on AMP at SFHTML5 Meetup on 23 Oct: http://www.meetup.com/de/sfhtml5/events/219966898/
I'm in.
On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz jkatz@wikimedia.org wrote:
On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN).
I think this announcement + the transcoding work Google is doing show that this ^ is something we should be strongly considering. If google can transcode our content and make it significantly faster (as Gergo showed in another thread) and/or other sites are adopting similar technology, than our users are going to expect a level of speed far higher than we can currently provide. I don't care if we use google's or our own, but do want to make sure we aren't rebuilding the wheel if we don't have to.
The conversations as to whether or not google is acting out of self interest are fairly moot (they are...always), but I think Luis's points are very apt about googles self interests being more closely aligned with ours on the web than the other big players in this space.
On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa lvilla@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
I agree that the companies all have (essentially[1]) the same motives at the company level. The difference is that Google's technical approach to solving the latency problem is not explicitly tied to Google or to particular Google apps. (There is a pure web demo, for example, which works in any mobile browser, including Firefox for Android, and Twitter - a Google competitor - has already adopted it.) In contrast, Facebook and Apple's "solutions" for fast reading are very explicitly tied to (1) apps, not browsers, and (2) apps specifically from those companies. There will never be a future where Facebook's solution for latency works outside of Facebook; there is (at least in theory, and possibly in practice w/ Twitter) such a future with AMP.
Or to put it another way: Google's solution still might not be good, but it's at least possible that it could keep content on the open web; Facebook and Apple are pretty explicitly trying to kill the open web. There is no way the long game of the FB/Apple apps lead to good outcomes for independent publishers like us.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere
Oh, definitely won't. But it might give us some leverage in those discussions - having conceded that the analytics from some cached pages should be shared, it is no longer such a huge leap to analytics on other types of "cached"/processed data.
and also might be troublesome for those who prefer google not to track their reading.
There is a lot of devil in those details, of course, but for those coming from Google Search (still the vast majority of our users) the first leap is already tracked/known to Google. This doesn't necessarily make that worse. (Much depends on how the caching occurs; their ability to track the *second* page you read would be new, at least for iOS users - Android users already have this problem, I believe.)
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
Great link, thanks.
[1] The subtle difference, from our perspective, is that Google has pretty strong incentives to keep the open web viable, because making sense of (and selling ads on) the open web is their core competence. Facebook and Apple, in contrast, have no strategic reason to keep the open web viable: if they can turn every publisher into a FB-only or Apple-only publisher, they'd happily do that. Of course, an open web that doesn't depend on Google would be even better, but that's not in the cards at this point unless Mozilla wakes up.
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two
- slim opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
> Hi Bryan, > > Ah, I was thinking of the 2 different mobile web editing experiences > (not 2 different apps) for Android depending on form factor. My > understanding is that tablets have VE enabled on mobile web now (I have yet > to try it) while phones do not have VE enabled on mobile web yet. > > Pine > On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote: > >> On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote: >> > We currently have at least 6 channels, I believe: >> > >> > 1. Desktop Web >> > 2. Mobile Web >> > 3. Android phone >> > 4. Android tablet >> >> I don't think that we have separate native apps for the phone and >> tablet form factors. >> >> > 5. IPhone >> > 6. Legacy Android phone >> > >> > I'm no expert on mobile developmemt, but perhaps WMF could >> experiment with >> > Google's idea on just one channel to start? >> >> AMP would only be appropriate for the mobile web channel from the >> list >> above. Implementing it would be a matter of placing some sort of >> translating proxy between MediaWiki and the requesting user agent >> that >> downgraded the HTML produced by MediaWiki to AMP's restricted HTML >> dialect. That sort of translation might be possible in >> MobileFrontend >> but it would likely be accomplished much more easily using some >> other >> tech stack that had good support for manipulation of HTML like a >> node.js service. It might be an interesting prototype project for a >> volunteer to experiment with a frontend app that consumed the >> RESTBase >> provided Parsoid HTML (e.g. >> https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out >> AMP >> compliant documents. >> >> The only other option really to produce alternate HTML from >> MediaWiki >> would require swapping out the existing layer that translates an >> article's wikitext to HTML with a version that spoke AMP instead. >> That >> would be related to https://phabricator.wikimedia.org/T114194. >> >> Bryan >> -- >> Bryan Davis Wikimedia Foundation < >> bd808@wikimedia.org> >> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID >> USA >> irc: bd808 v:415.839.6885 >> x6855 >> > _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Mon, Oct 12, 2015 at 12:50 PM, Volker Eckl veckl@wikimedia.org wrote:
Google will give an introduction on AMP at SFHTML5 Meetup on 23 Oct: http://www.meetup.com/de/sfhtml5/events/219966898/
I'm in.
FWIW, Google appears to be serious about this: http://searchengineland.com/google-amp-coming-rank-fast-238046
Luis
On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz jkatz@wikimedia.org wrote:
On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN).
I think this announcement + the transcoding work Google is doing show that this ^ is something we should be strongly considering. If google can transcode our content and make it significantly faster (as Gergo showed in another thread) and/or other sites are adopting similar technology, than our users are going to expect a level of speed far higher than we can currently provide. I don't care if we use google's or our own, but do want to make sure we aren't rebuilding the wheel if we don't have to.
The conversations as to whether or not google is acting out of self interest are fairly moot (they are...always), but I think Luis's points are very apt about googles self interests being more closely aligned with ours on the web than the other big players in this space.
On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa lvilla@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
I agree that the companies all have (essentially[1]) the same motives at the company level. The difference is that Google's technical approach to solving the latency problem is not explicitly tied to Google or to particular Google apps. (There is a pure web demo, for example, which works in any mobile browser, including Firefox for Android, and Twitter - a Google competitor - has already adopted it.) In contrast, Facebook and Apple's "solutions" for fast reading are very explicitly tied to (1) apps, not browsers, and (2) apps specifically from those companies. There will never be a future where Facebook's solution for latency works outside of Facebook; there is (at least in theory, and possibly in practice w/ Twitter) such a future with AMP.
Or to put it another way: Google's solution still might not be good, but it's at least possible that it could keep content on the open web; Facebook and Apple are pretty explicitly trying to kill the open web. There is no way the long game of the FB/Apple apps lead to good outcomes for independent publishers like us.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere
Oh, definitely won't. But it might give us some leverage in those discussions - having conceded that the analytics from some cached pages should be shared, it is no longer such a huge leap to analytics on other types of "cached"/processed data.
and also might be troublesome for those who prefer google not to track their reading.
There is a lot of devil in those details, of course, but for those coming from Google Search (still the vast majority of our users) the first leap is already tracked/known to Google. This doesn't necessarily make that worse. (Much depends on how the caching occurs; their ability to track the *second* page you read would be new, at least for iOS users - Android users already have this problem, I believe.)
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
Great link, thanks.
[1] The subtle difference, from our perspective, is that Google has pretty strong incentives to keep the open web viable, because making sense of (and selling ads on) the open web is their core competence. Facebook and Apple, in contrast, have no strategic reason to keep the open web viable: if they can turn every publisher into a FB-only or Apple-only publisher, they'd happily do that. Of course, an open web that doesn't depend on Google would be even better, but that's not in the cards at this point unless Mozilla wakes up.
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two
- slim opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Bryan and Pine.
My feeling is that there are many many new interfaces and form factors emerging right now and we should be cautious about adoption. For example Facebook's instant articles, apple news and even snapchat have similar offerings the AMP.
They all seem to be focusing on article speed in a landscape where most pages are larded up with a variety of trackers, ads and other scripts (which we don't have, although we have our own challenges on performance) with the ultimate goal of owning the delivery platform.
I'm nervous about picking winners in such a landscape although I'm excited about prototypes like things like the Apple Watch app that came out of the Lyon hackathon. I feel like a slow follower model where we see which solution if any becomes widely used is more appropriate for us.
-Toby
On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote:
> Hi Bryan, > > Ah, I was thinking of the 2 different mobile web editing experiences > (not 2 different apps) for Android depending on form factor. My > understanding is that tablets have VE enabled on mobile web now (I have yet > to try it) while phones do not have VE enabled on mobile web yet. > > Pine > On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote: > >> On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com wrote: >> > We currently have at least 6 channels, I believe: >> > >> > 1. Desktop Web >> > 2. Mobile Web >> > 3. Android phone >> > 4. Android tablet >> >> I don't think that we have separate native apps for the phone and >> tablet form factors. >> >> > 5. IPhone >> > 6. Legacy Android phone >> > >> > I'm no expert on mobile developmemt, but perhaps WMF could >> experiment with >> > Google's idea on just one channel to start? >> >> AMP would only be appropriate for the mobile web channel from the >> list >> above. Implementing it would be a matter of placing some sort of >> translating proxy between MediaWiki and the requesting user agent >> that >> downgraded the HTML produced by MediaWiki to AMP's restricted HTML >> dialect. That sort of translation might be possible in >> MobileFrontend >> but it would likely be accomplished much more easily using some >> other >> tech stack that had good support for manipulation of HTML like a >> node.js service. It might be an interesting prototype project for a >> volunteer to experiment with a frontend app that consumed the >> RESTBase >> provided Parsoid HTML (e.g. >> https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out >> AMP >> compliant documents. >> >> The only other option really to produce alternate HTML from >> MediaWiki >> would require swapping out the existing layer that translates an >> article's wikitext to HTML with a version that spoke AMP instead. >> That >> would be related to https://phabricator.wikimedia.org/T114194. >> >> Bryan >> -- >> Bryan Davis Wikimedia Foundation < >> bd808@wikimedia.org> >> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID >> USA >> irc: bd808 v:415.839.6885 >> x6855 >> > _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Thanks, Luis!
A search for Barack Obama surfaces a news carousel of AMPed articles that push us down significantly (see link below on a mobile device).
Greater web speeds on mobile overall are a good thing for internet users and put pressure on us to move fast or be punished. Since I know nothing for wmf projects is being implemented to this end before February, we'll have to watch carefully to see how this impacts our search traffic (i.e. most of our traffic) is impacted when google rolls it out.
https://www.google.com/webhp?esrch=AcceleratedMobilePages::Preview,Accelerat...
On Wed, Dec 9, 2015 at 12:41 PM, Luis Villa lvilla@wikimedia.org wrote:
On Mon, Oct 12, 2015 at 12:50 PM, Volker Eckl veckl@wikimedia.org wrote:
Google will give an introduction on AMP at SFHTML5 Meetup on 23 Oct: http://www.meetup.com/de/sfhtml5/events/219966898/
I'm in.
FWIW, Google appears to be serious about this: http://searchengineland.com/google-amp-coming-rank-fast-238046
Luis
On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz jkatz@wikimedia.org wrote:
On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
If you really wanted to, you can subset what you send to mobile browsers and get the same benefits (provided you use a really good CDN).
I think this announcement + the transcoding work Google is doing show that this ^ is something we should be strongly considering. If google can transcode our content and make it significantly faster (as Gergo showed in another thread) and/or other sites are adopting similar technology, than our users are going to expect a level of speed far higher than we can currently provide. I don't care if we use google's or our own, but do want to make sure we aren't rebuilding the wheel if we don't have to.
The conversations as to whether or not google is acting out of self interest are fairly moot (they are...always), but I think Luis's points are very apt about googles self interests being more closely aligned with ours on the web than the other big players in this space.
On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa lvilla@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin tnegrin@wikimedia.org wrote:
Hi Luis --
I honestly don't see a lot of difference between Google, Twitter and Facebook, since they are all ad supported entities with a fiscal responsibility to track their users and sell the data. Apple's a bit different on the surface since they have a different business model. I agree that these are bad for the internet but so are incredibly slow web pages that make apps essentially required for a good experience.
I agree that the companies all have (essentially[1]) the same motives at the company level. The difference is that Google's technical approach to solving the latency problem is not explicitly tied to Google or to particular Google apps. (There is a pure web demo, for example, which works in any mobile browser, including Firefox for Android, and Twitter - a Google competitor - has already adopted it.) In contrast, Facebook and Apple's "solutions" for fast reading are very explicitly tied to (1) apps, not browsers, and (2) apps specifically from those companies. There will never be a future where Facebook's solution for latency works outside of Facebook; there is (at least in theory, and possibly in practice w/ Twitter) such a future with AMP.
Or to put it another way: Google's solution still might not be good, but it's at least possible that it could keep content on the open web; Facebook and Apple are pretty explicitly trying to kill the open web. There is no way the long game of the FB/Apple apps lead to good outcomes for independent publishers like us.
On the analytics, this would probably not include their use of our content in the knowledge graph or elsewhere
Oh, definitely won't. But it might give us some leverage in those discussions - having conceded that the analytics from some cached pages should be shared, it is no longer such a huge leap to analytics on other types of "cached"/processed data.
and also might be troublesome for those who prefer google not to track their reading.
There is a lot of devil in those details, of course, but for those coming from Google Search (still the vast majority of our users) the first leap is already tracked/known to Google. This doesn't necessarily make that worse. (Much depends on how the caching occurs; their ability to track the *second* page you read would be new, at least for iOS users - Android users already have this problem, I believe.)
Bryan's ticket is a good embarkation point for thinking about supporting new clients; Reading is also planning some Reading infrastructure work for the summit which could relate[1]
Great link, thanks.
[1] The subtle difference, from our perspective, is that Google has pretty strong incentives to keep the open web viable, because making sense of (and selling ads on) the open web is their core competence. Facebook and Apple, in contrast, have no strategic reason to keep the open web viable: if they can turn every publisher into a FB-only or Apple-only publisher, they'd happily do that. Of course, an open web that doesn't depend on Google would be even better, but that's not in the cards at this point unless Mozilla wakes up.
On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa lvilla@wikimedia.org wrote:
Toby -
I'm generally 1000% on-board with slow follower for anything user-facing. The only reason I might make an exception here is because the competitors you mention are all pretty awful for the web generally, and this has uptake already from Google and Twitter. (Two isn't great, but two
- slim opportunity for growth is way better than the guaranteed
never-greater-than-1 we'll see from FB's option.)
The other reason this intrigues me is that if Google builds in some analytics, it might give us a better sense of their current usages for us than we currently have. Not much, obviously, but at least something. (Remember that in this scenario - direct access from Google properties - they already have all that information, the only question is whether it gets shared with us so that we can do something useful with it.)
That said, if implementing it is non-trivial, it doesn't make sense to spend a huge number of cycles to fast-follow. Hopefully some of the improvements Bryan mentions will make it easier in the future - it certainly doesn't look like we're in a world where the number of front ends is going to get smaller any time soon.
Luis
On Thu, Oct 8, 2015 at 1:25 PM, Toby Negrin tnegrin@wikimedia.org wrote:
> Thanks Bryan and Pine. > > My feeling is that there are many many new interfaces and form > factors emerging right now and we should be cautious about adoption. For > example Facebook's instant articles, apple news and even snapchat have > similar offerings the AMP. > > They all seem to be focusing on article speed in a landscape where > most pages are larded up with a variety of trackers, ads and other scripts > (which we don't have, although we have our own challenges on performance) > with the ultimate goal of owning the delivery platform. > > I'm nervous about picking winners in such a landscape although I'm > excited about prototypes like things like the Apple Watch app that came out > of the Lyon hackathon. I feel like a slow follower model where we see which > solution if any becomes widely used is more appropriate for us. > > -Toby > > > On Thursday, October 8, 2015, Pine W wiki.pine@gmail.com wrote: > >> Hi Bryan, >> >> Ah, I was thinking of the 2 different mobile web editing >> experiences (not 2 different apps) for Android depending on form factor. My >> understanding is that tablets have VE enabled on mobile web now (I have yet >> to try it) while phones do not have VE enabled on mobile web yet. >> >> Pine >> On Oct 8, 2015 12:56 PM, "Bryan Davis" bd808@wikimedia.org wrote: >> >>> On Thu, Oct 8, 2015 at 1:32 PM, Pine W wiki.pine@gmail.com >>> wrote: >>> > We currently have at least 6 channels, I believe: >>> > >>> > 1. Desktop Web >>> > 2. Mobile Web >>> > 3. Android phone >>> > 4. Android tablet >>> >>> I don't think that we have separate native apps for the phone and >>> tablet form factors. >>> >>> > 5. IPhone >>> > 6. Legacy Android phone >>> > >>> > I'm no expert on mobile developmemt, but perhaps WMF could >>> experiment with >>> > Google's idea on just one channel to start? >>> >>> AMP would only be appropriate for the mobile web channel from the >>> list >>> above. Implementing it would be a matter of placing some sort of >>> translating proxy between MediaWiki and the requesting user agent >>> that >>> downgraded the HTML produced by MediaWiki to AMP's restricted HTML >>> dialect. That sort of translation might be possible in >>> MobileFrontend >>> but it would likely be accomplished much more easily using some >>> other >>> tech stack that had good support for manipulation of HTML like a >>> node.js service. It might be an interesting prototype project for a >>> volunteer to experiment with a frontend app that consumed the >>> RESTBase >>> provided Parsoid HTML (e.g. >>> https://en.wikipedia.org/api/rest_v1/page/html/NOFX) and spit out >>> AMP >>> compliant documents. >>> >>> The only other option really to produce alternate HTML from >>> MediaWiki >>> would require swapping out the existing layer that translates an >>> article's wikitext to HTML with a version that spoke AMP instead. >>> That >>> would be related to https://phabricator.wikimedia.org/T114194. >>> >>> Bryan >>> -- >>> Bryan Davis Wikimedia Foundation < >>> bd808@wikimedia.org> >>> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID >>> USA >>> irc: bd808 v:415.839.6885 >>> x6855 >>> >> > _______________________________________________ > Mobile-l mailing list > Mobile-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*
Luis Villa, 09/12/2015 21:41:
FWIW, Google appears to be serious about this: http://searchengineland.com/google-amp-coming-rank-fast-238046
How does that different from their long-standing habit of sending Google search mobile users to Google caches or other stripped down versions of websites, which AFAIK has been in place since before Android?
Tilman Bayer, 08/10/2015 19:23:
Yes, the Niemanlab summary is really informative. Read it last night and this part kind of jumped out at me:
/"There are lots of clever ideas here, and it’s understandable why these constraints would help improve performance. For better and for worse, this is essentially a rollback of how HTML and web technologies have evolved over the past decade. It’s a little jarring that so many of the sample AMP pages on display this morning look a lot like the web of, say, 2002, shrunk down to a phone screen.: "// / Reminds one of a certain website that's often accused (quite rightfully) of being stuck in 2002...
Reverting a decade of JavaScript frenzy sounds fantastic to me!
Nemo
On Thu, Oct 8, 2015 at 2:10 PM, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences (not 2 different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it) while phones do not have VE enabled on mobile web yet.
AMP doesn't allow forms or custom javascript so VE (or any other editing experience) would be right out. Honestly this just looks like Google trying to setup a standard for acting as a CDN for static content.
Bryan
Aha, that might make sense. Would it be worth WMF time to discuss the possibilities (cynical and benevolent) with them via an in-person contact?
In general I am less suspicious of Google than I am of some other big Web companies, although perhaps my trust is misplaced.
Pine On Oct 8, 2015 3:30 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 2:10 PM, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences
(not 2
different apps) for Android depending on form factor. My understanding is that tablets have VE enabled on mobile web now (I have yet to try it)
while
phones do not have VE enabled on mobile web yet.
AMP doesn't allow forms or custom javascript so VE (or any other editing experience) would be right out. Honestly this just looks like Google trying to setup a standard for acting as a CDN for static content.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855
And, upon rereading Bryan's most recent email, I'm not sure that I'm interpreting it correctly, which probably means that I should be quiet and listen to those who know more about this subject than I do.
Pine On Oct 8, 2015 4:32 PM, "Pine W" wiki.pine@gmail.com wrote:
Aha, that might make sense. Would it be worth WMF time to discuss the possibilities (cynical and benevolent) with them via an in-person contact?
In general I am less suspicious of Google than I am of some other big Web companies, although perhaps my trust is misplaced.
Pine On Oct 8, 2015 3:30 PM, "Bryan Davis" bd808@wikimedia.org wrote:
On Thu, Oct 8, 2015 at 2:10 PM, Pine W wiki.pine@gmail.com wrote:
Hi Bryan,
Ah, I was thinking of the 2 different mobile web editing experiences
(not 2
different apps) for Android depending on form factor. My understanding
is
that tablets have VE enabled on mobile web now (I have yet to try it)
while
phones do not have VE enabled on mobile web yet.
AMP doesn't allow forms or custom javascript so VE (or any other editing experience) would be right out. Honestly this just looks like Google trying to setup a standard for acting as a CDN for static content.
Bryan
Bryan Davis Wikimedia Foundation bd808@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855