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,AcceleratedMobilePagesDesktop::Promo#esrch=AcceleratedMobilePages::Preview%2CAcceleratedMobilePagesDesktop::Promo&q=barack+obama On Wed, Dec 9, 2015 at 12:41 PM, Luis Villa <lvi...@wikimedia.org> wrote: > On Mon, Oct 12, 2015 at 12:50 PM, Volker Eckl <ve...@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 <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 >>> >>> >> > > > -- > 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
