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(a)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-web-burn-it-down/
<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(a)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(a)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(a)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(a)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(a)wikimedia.org> wrote:
>
>> On Thu, Oct 8, 2015 at 1:32 PM, Pine W <wiki.pine(a)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(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l