Re: [WikimediaMobile] Some interesting stuff from Google

[Pine W]

Cool.

Pine
On Oct 8, 2015 8:05 AM, "Jon Katz"  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-the-mobile-web?utm_source=rss1.0mainlinkanon_medium=feed
>
>
> Google has officially taken the wraps off its AMP project — Accelerated
> Mobile Pages  — which aims to speed up the
> delivery of web content to mobile devices
> . 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  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  has a few
> more details.
>
> Google blog announcement:
>
> https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html
>
> ___
> 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

Re: [WikimediaMobile] Some interesting stuff from Google

[Luis Villa]

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-about-googles-new-plan-to-speed-up-your-website/

On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz  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-the-mobile-web?utm_source=rss1.0mainlinkanon_medium=feed
>
>
> Google has officially taken the wraps off its AMP project — Accelerated 
> Mobile Pages  — which aims to speed up the 
> delivery of web content to mobile devices 
> . 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  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  has a few 
> more details.
>
> Google blog announcement:
>
> https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html
>
> ___
> 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

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Tilman Bayer]

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  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-about-googles-new-plan-to-speed-up-your-website/
>
> On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz  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-the-mobile-web?utm_source=rss1.0mainlinkanon_medium=feed
>>
>>
>> Google has officially taken the wraps off its AMP project — Accelerated
>> Mobile Pages  — which aims to speed up the
>> delivery of web content to mobile devices
>> . 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  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  has a few
>> more details.
>>
>> Google blog announcement:
>>
>> https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html
>>
>> ___
>> 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-...@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

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Derk-Jan Hartman]

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  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  > 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-about-googles-new-plan-to-speed-up-your-website/
>  
> 
> 
> On Thu, Oct 8, 2015 at 8:05 AM, Jon Katz  > 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-the-mobile-web?utm_source=rss1.0mainlinkanon_medium=feed
>  
> 
> 
> 
> Google has officially taken the wraps off its AMP project — Accelerated 
> Mobile Pages  — which aims to speed up the 
> delivery of web content to mobile devices 
> . 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 
>  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  has a 
> few more details.
> 
> 
> Google blog announcement:
> https://googleblog.blogspot.com/2015/10/introducing-accelerated-mobile-pages.html
>  
> 
> ___
> 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-...@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 

Re: [WikimediaMobile] Some interesting stuff from Google

[Toby Negrin]

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  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"  > wrote:
>
>> On Thu, Oct 8, 2015 at 1:32 PM, Pine W > > 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> >
>> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
>> irc: bd808v:415.839.6885 x6855
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Bryan Davis]

On Thu, Oct 8, 2015 at 2:10 PM, Pine W  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
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Pine W]

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"  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"  wrote:
>
>> On Thu, Oct 8, 2015 at 2:10 PM, Pine W  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
>> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
>> irc: bd808v:415.839.6885 x6855
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Pine W]

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"  wrote:

> On Thu, Oct 8, 2015 at 2:10 PM, Pine W  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
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Some interesting stuff from Google

[Luis Villa]

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  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  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"  wrote:
>>
>>> On Thu, Oct 8, 2015 at 1:32 PM, Pine W  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
>>> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
>>> irc: bd808v: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

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Pine W]

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"  wrote:

> On Thu, Oct 8, 2015 at 1:32 PM, Pine W  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
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Some interesting stuff from Google

[Toby Negrin]

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  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  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  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"  wrote:
>>>
 On Thu, Oct 8, 2015 at 1:32 PM, Pine W  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 

Re: [WikimediaMobile] [reading-wmf] Some interesting stuff from Google

[Bryan Davis]

On Thu, Oct 8, 2015 at 1:32 PM, Pine W  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
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l