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 > <javascript:_e(%7B%7D,'cvml','bd...@wikimedia.org');>> wrote: > >> On Thu, Oct 8, 2015 at 1:32 PM, Pine W <wiki.p...@gmail.com >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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
