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 <jk...@wikimedia.org> wrote:

>
> On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez <
> jhernan...@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 <lvi...@wikimedia.org> wrote:
>
>> On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin <tneg...@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]
>>>
>>
>>> [1] https://phabricator.wikimedia.org/T114542
>>>
>>
>> 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 <lvi...@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 <tneg...@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.p...@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" <bd...@wikimedia.org> wrote:
>>>>>>
>>>>>>> On Thu, Oct 8, 2015 at 1:32 PM, Pine W <wiki.p...@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    <
>>>>>>> bd...@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

Reply via email to